Using Claude Code to Improve our Employee Class

Employees, Day 2: Add a Feature with Claude Code

Today your group adds a new feature to the employee project you built last time. You’ll use Claude Code to help write it, but you are the designer. Before Claude writes anything, your group decides what the feature does, breaks it into parts, and writes pseudocode. Then you’ll guide Claude, review every change it makes, and test the result in Thonny. The times next to each part keep you on pace for a 50-minute class.

Before you start (2 min)

  1. Your laptop has the Claude desktop app installed and is signed in to the course’s Claude group. (If not, follow the Installing Thonny and Claude Code page first.)
  2. Open your employee_project folder from last time in Thonny and run main.py. Make sure it still works.
  3. Make a backup. In File Explorer (Windows) or Finder (Mac), copy your whole employee_project folder and name the copy employee_project_backup. If anything goes badly wrong today, you can start over from the copy.

Part 1: Choose Your Feature (5 min)

Pick at least one of these features. Read all four before deciding. The sample outputs are just ideas; your version can look different.

Option 1: Friend network

Each employee has a list of friends (self.friends). You can make two employees friends, and the program prints the whole friend network.

Friend network:
Bill Yeakus  -- Sally Smith, Joan Jones
Sally Smith  -- Bill Yeakus
Joan Jones   -- Bill Yeakus

Option 2: Sales tracker

Employees record sales. The program totals each employee’s sales, calculates their commission (a percentage of sales), and awards a bonus to anyone who beats a sales target.

Sales report:
Bill Yeakus   Sales: $12000   Commission: $600    Bonus: $0
Sally Smith   Sales: $31000   Commission: $1550   Bonus: $1000

Option 3: Work schedule

Each employee has the days of the week they work. The program prints a weekly grid showing who works each day.

              Mon  Tue  Wed  Thu  Fri
Bill Yeakus    X         X         X
Sally Smith    X    X    X    X
Joan Jones          X         X    X

Option 4: Wild card

Invent your own. A few ideas: performance reviews and raises, birthdays and anniversaries, or an org chart showing who reports to whom. Keep it about the size of the options above.

Q1. Only if you chose Option 4: describe your feature in one or two sentences. What will someone see when they run main.py after you add it?

Part 2: Break It into Parts and Write Pseudocode (12 min)

Every feature is made of a few pieces: new data each employee stores, new methods that use or change that data, a demo in main.py that shows it working, and a tricky case to handle carefully. Here’s a breakdown for a feature that isn’t on the list, written as a comment at the top of main.py:

# FEATURE: Vacation day tracker
# New data: self.vacation_days, starts at 15 for every employee
# New methods:
#   take_vacation(days): subtracts days if the employee has enough,
#                        otherwise prints a warning
#   vacation_report(): prints how many days the employee has left
# Demo: Bill takes 3 days, Sally tries to take 20, then print everyone's report
# Tricky case: someone tries to take more days than they have

Q2. Open main.py in Thonny and write the same kind of breakdown for your feature as a comment at the very top of the file. Start every line with # so Python ignores it. Your comment should cover:

  • New data: what new attributes will each employee need? What does each one start as? Does anything need to be shared by the whole class, like empCount?
  • New methods: list each method’s name and parameters, and say in a few words what it does. Does it print something, return something, or change the employee’s data?
  • Demo in main.py: what steps will main.py take to show the feature working?
  • Tricky case: what is one situation your feature should handle carefully?

Keep it small: two or three methods is plenty for today. Save main.py and run it to make sure the comment didn’t break anything.

Pseudocode is a step-by-step plan written in plain English, structured like code but without worrying about Python syntax. Here’s pseudocode for one method from the vacation example:

take_vacation(days):
    if days is more than my vacation_days:
        print a warning: "[name] only has [vacation_days] days left"
    otherwise:
        subtract days from my vacation_days
        print "[name] took [days] days off"

Q3. Write pseudocode for every method from your breakdown. Check your pseudocode against this list:

  • It uses the same data and method names as your breakdown.
  • Each method says what it gets (parameters), what steps it takes, and what it prints, returns, or changes.
  • It handles your tricky case.
  • Someone outside your group could read it and know what to build.

Type your pseudocode somewhere you can copy it from, such as a new Thonny tab saved as pseudocode.txt in your project folder. You’ll give it to Claude in Part 4.

Part 3: Set Up Claude Code (4 min)

  1. Save your work in Thonny (every tab), then close employee.py and main.py in Thonny. This prevents Thonny and Claude from editing the same file at the same time.
  2. Open the Claude desktop app. Click your initials in the lower-left corner and make sure the course group has the blue checkmark.
  3. Click Code at the top of the left sidebar. If a previous session is open, click + New to start a fresh one.
  4. In the row of controls under the message box, set these before you type anything:
    • Environment: click the first control and choose the top option under Local, so Claude works on files on your own laptop.
    • Folder: click the folder control, choose Open folder…, and select your employee_project folder (not the backup).
    • Model: click the model picker near the right end of the row and choose Sonnet. It’s fast and capable enough for this project, and it uses less of the course’s shared usage than Opus.
    • Effort: in the same model menu, under Effort, choose Medium. Effort controls how long Claude thinks before it acts. Medium is plenty for a feature this size; higher levels are slower and use more.
    • Permission mode: click the mode selector and choose Plan for now. In Plan mode Claude can read your files and propose a plan, but it can’t change anything.

Why these settings? Plan mode lets you check Claude’s plan before any code is written. In Part 5 you’ll switch to Manual, so Claude has to show you every change and wait for your approval. Don’t use Auto or Accept edits today: those let Claude change files without asking, and today the point is that your group reviews every line.

Part 4: Get a Plan from Claude (4 min)

Copy this message into Claude’s message box, fill in the brackets, and paste in your pseudocode from Q3. Then press Enter.

We're beginning Python students. Read employee.py and main.py.
We want to add this feature: [the option you chose, or your Option 4 description]
Our breakdown of the feature is in the comment at the top of main.py.

Here is our plan in pseudocode:

[paste your pseudocode here]

Please make a plan to add this feature. Rules: – Keep all of our existing code working. – Use only basic Python we would know: classes, methods, lists, loops, if statements, and f-strings. No imports or outside libraries. – Explain each change in plain language a beginner can follow. – Don’t run any commands. We will run and test the code in Thonny.

Read Claude’s plan together as a group.

Q4. Compare Claude’s plan to your pseudocode. Name one thing Claude did differently or added. Which version do you prefer for that part?

If you want anything changed, type it as a reply (for example, “Use our method name take_vacation instead of use_days”) and let Claude revise the plan. Don’t spend more than a minute or two here.

Part 5: Build It in Manual Mode (12 min)

  1. Click the mode selector and switch to Manual. (If Claude offers to start building, choose the option that keeps you approving each change.)
  2. Type: Go ahead and implement the plan, one method at a time.
  3. For each change Claude proposes, it shows you a diff: red lines will be removed and green lines will be added. Before you accept it:
    • Read the change out loud as a group.
    • If anyone can’t explain what a line does, reject it or ask Claude, e.g. “Explain line 3 of that change before we accept it.”
    • If it doesn’t match your plan, reject it and tell Claude what you want instead.
  4. If Claude asks permission to run a command (for example, python main.py), deny it and remind Claude: “Don’t run commands; we’ll test in Thonny.” Your Python lives inside Thonny, so commands like this often fail on your laptop anyway.

Tips: to stop Claude at any time, click the stop button or press Esc. To point Claude at a specific file, type @ and the file name, like @employee.py. If the conversation gets confusing, click + New to start a fresh session (set Model, Effort, and Mode again).

Q5. Did your group reject or question any of Claude’s changes? What was it, and what happened?

Part 6: Run and Test in Thonny (8 min)

  1. In Thonny, reopen employee.py and main.py from your project folder so you see Claude’s changes. (If Thonny asks whether to reload a file that changed, click Yes.)
  2. Select the main.py tab and click Run.
  3. If you get an error, copy the full red error message into Claude and ask it to explain the error first, before fixing it. Make sure you understand the explanation, then let it propose a fix (still in Manual mode).
  4. Test your tricky case. Does the program handle it?

Q6 (optional). Did the output look the way you expected? Did you hit any bugs, and how did you fix them?

Wrap-Up (3 min)

Q7. How did writing pseudocode first change what you asked Claude for?

Scroll to Top