Performance Task

Overview

The AP CSP Create Performance Task is the project portion of the AP Computer Science Principles exam, and it counts for 30% of your AP score. You get 9 hours of in-class time to develop a program, record a video of it running, and write a Personalized Project Reference (PPR), all submitted through the AP Digital Portfolio by the end-of-April deadline. Then, on the end-of-course exam in May, you answer 2 written-response questions (4 prompts total) about your project in 60 minutes, with your PPR in front of you.

The other 70% of your score comes from the 70-question multiple-choice section, which runs 120 minutes. So the AP CSP exam really has two halves: a long-term project you build during the school year, and an exam day where you answer questions about both course content and your own code.

The big mindset shift is this: the Create task is not just a coding project. Plenty of students build programs that work great and still lose points because they can't explain their design decisions on exam day. Your code, your video, and your written responses all have to work together.

How the AP CSP Create Task Is Scored

The Create Performance Task is worth 30% of your AP score and is graded based on four pieces: your program code, your video, your Personalized Project Reference, and your written responses on the end-of-course exam. Here's what each piece is and what it has to include.

The four written-response prompts are set categories, so you can prepare for them all year:

One detail that trips people up every year: if you don't submit your PPR as final in the AP Digital Portfolio, you will not have access to it on exam day. You'd be answering questions about your code from memory. Submit everything as final, on time.

Heads up: College Board has announced an updated AP CSP course framework starting in the 2027-28 school year. If you're testing in 2026 or 2027, the format described here is current. Testing after that, double-check official directions.

How to Approach the Create Task, Step by Step

You have 9 hours of dedicated class time to produce the program, video, and PPR. That sounds like a lot until you're in hour seven debugging a loop. Here's a realistic way to spend it.

Hour 1: Pick a project you can explain

The best project sits in the sweet spot between personal interest and manageable complexity. You need enough substance to show a meaningful list, a real procedure, and an algorithm with sequencing, selection, and iteration. You don't need a neural network. A well-explained tic-tac-toe game beats a poorly-understood machine learning project every time, because the written responses reward understanding, not ambition.

Before you write code, sketch your plan. Decide what your list will store, what your main procedure will do, and what problem the program solves. Strong past projects include grade calculators, simple games with interesting mechanics, sports stat analyzers, and music or art generators. The complexity should come from your algorithm choices, not from a library doing the work for you.

Hours 2-6: Build incrementally and keep a journal

Get basic functionality working first, then add features. Test as you go instead of waiting until the end. This is also where collaboration is allowed: you can work with classmates during ideation and program development, including error testing. Use that.

Keep a programming journal the whole time. Note why you chose your data structure, what your procedure encapsulates, what bugs you hit, and how you fixed them. On exam day you'll be writing about exactly these things, weeks after you finished coding. Students who document as they go write dramatically better responses than students reconstructing their thought process from memory.

Two design choices deserve extra attention because they map directly to WR2(c):

Your list should be necessary. A list holding three values you could've stored in three variables is weak material. A list that represents your game state, gets searched by your algorithm, or makes the program scalable gives you something real to write about.

Your procedure should take at least one parameter and actually use it. Strategically, the strongest procedures hide a complex process behind a simple call, so you can explain how the abstraction manages complexity rather than just saying "it avoids repeating code."

Hours 7-8: Test deliberately, then record the video

Testing isn't just running the program to see if it works. Pick specific inputs, predict the result, run the test, and record what happened. Edge cases (empty input, negative numbers, the largest expected value) make the best written-response material because they often reveal real bugs you then fixed. That before-and-after story is exactly what WR2(b) asks about.

Then record your video. It must show input going into the program, at least one aspect of the program's functionality, and the output produced. No voice narration is allowed, and nothing in the video can identify you. Watch it on a different device before submitting to make sure the resolution is readable. You must create the video on your own; no collaboration here.

Hour 9: Build your PPR and capture your code

Your PPR contains code segments from your program, including the code for your list and your procedure. Choose segments you can write about fluently, because these are the exact segments the exam prompts will reference. You create the PPR independently.

For code capture, text-based code can be printed or pasted into a document and converted to PDF. Block-based code should be screenshotted clearly (code only, text at least 10 pt, not blurry) and assembled into a PDF.

Before exam day: Rehearse the four prompts

You know the four prompt categories in advance, so practice them. Explain your program's purpose and function out loud. Walk through your algorithm step by step. Retell your best testing story. Explain how your list and procedure manage complexity. If you can do all four without looking at your code, the 60-minute written-response section becomes very manageable.

Writing Strong Responses: Verbs and Examples

The written-response prompts use specific task verbs, and answering the verb you were actually asked is half the battle. These are the official ones:

• "Identify" means name it, no elaboration needed.
• "Describe" means give the relevant features or characteristics. That's the "what."
• "Explain" means give the how or why, with detailed steps or evidence and reasoning.
• "Capture" means select the portion of code that addresses the prompt.
• "Demonstrate" means provide sufficient evidence for the point you're making.

If a prompt says "explain" and you only describe, you've answered a different question.

Here's the difference between weak and strong answers, using testing as the example.

Weak (editorial example): "I tested my program with different values and fixed the bugs I found."

Strong (editorial example): "I tested with a negative number as input, expecting an error message, but the program crashed instead. This led me to add input validation that checks for negative values before processing. After the fix, the same input correctly displayed the error message."

The strong version names the specific input, the expected result, the actual result, and the refinement it caused. Apply the same specificity to abstraction. Don't write "the list makes my code simpler." Write what the code would look like without the list (dozens of separate variables, repeated if-statements, no way to add new items) and why that alternative breaks down.

Two more habits that pay off. Use CS vocabulary precisely: a "list" is a specific data structure, "iteration" means loops, an "algorithm" is a logical sequence of steps, not just "my code." If you need a refresher on terms, the AP CSP key terms glossary is a quick check. And when referencing code, point only to the segments relevant to the prompt rather than gesturing at your whole program.

Common Mistakes

• Treating it as just a coding project. The written responses are 30% of your exam working against you if you can't explain your own design. Fix it by keeping a journal during development and rehearsing the four prompt categories before May.
• Not submitting the PPR as final. If your PPR isn't finalized in the AP Digital Portfolio, you answer the written responses with no reference at all. Confirm your final submission well before the deadline.
• Collaborating on the wrong components. Working together is allowed only during ideation and program development, including error testing. The video, the PPR, and the written responses must be entirely your own. Even paraphrasing a partner's explanation counts as plagiarism.
• Letting a library do the work. You can use APIs and libraries with credit, but the prompts ask about your list, your procedure, and your algorithm. If a library implements your core logic, you have nothing of your own to write about. Use libraries for auxiliary stuff like graphics and keep the core logic yours.
• A video that breaks the rules. Missing input or output, voice narration, blurry footage, or identifying information all cause avoidable problems. Re-watch your video against the three requirements (input, functionality, output) before uploading.
• Choosing complexity you can't explain. An impressive program with vague explanations scores worse than a modest program with precise ones. Pick a scope where you understand every line.

Practice and Next Steps

Start by getting the full exam picture on the AP CSP exam prep page, then read the MCQ section guide since multiple choice carries the other 70% of your score. To rehearse explaining code under time pressure, run through written-response practice with instant scoring and drill content with guided MCQ practice. When you want a dress rehearsal, take a full-length AP CSP practice exam, then plug your results into the AP CSP score calculator to see how your Create task and MCQ performance combine into a final score.