TL;DR:
Pair programming with an assistant works best when you describe intent, take small steps and run the tests after each one.
A failing test is a precise question: this input should give this output. Start from it.
You decide what goes into your code. Read every change before you keep it.
Pair programming means two people share one problem: one types, the other watches and thinks. An assistant that can see your editor can take the watching and thinking seat. The question is how to use it so that you finish with working code and understand why it works.
The short answer
Start from a failing test, tell the assistant what you meant the code to do, and ask for the smallest possible step. Run the test, look at the result, and repeat. You stay in control because you are the one running the code and deciding what stays.
What happens step by step
Run the test and leave the failure on screen. The red line, the expected value and the actual value are the best clues anyone can have.
Describe intent. Say what the function is meant to do in one sentence, in your words.
Ask for a hypothesis, not a rewrite. "What would make this input give that output?" teaches more than "fix it".
Make one small change. Edit one line, or one condition.
Run the tests again. The result decides what is next, not anybody's confidence.
Walk-through: fixing a failing test together
You wrote a function to decide whether a year is a leap year, and one test fails.
def is_leap_year(year):
return year % 4 == 0
assert is_leap_year(2024) == True
assert is_leap_year(2000) == True
assert is_leap_year(1900) == FalseThe first two assertions pass and the third fails: the function says 1900 is a leap year. You tell the assistant: "A leap year is every fourth year, but I think there are exceptions." That is your intent, half formed, and it is enough.
Step 1: find out what is true
The calendar rule is: a year is a leap year if it is divisible by 4, except century years, which must also be divisible by 400. Check the failing case. 1900 ÷ 4 = 475, so it passes the current test. But 1900 is a century year and 1900 ÷ 400 = 4.75, so it is not a leap year. The test is right and the function is incomplete.
Step 2: a small change
Rather than rewriting the file, change only the return line.
def is_leap_year(year):
return (year % 4 == 0 and year % 100 != 0) or year % 400 == 0Step 3: check every case by hand
Year | Divisible by 4 | Century year | Divisible by 400 | Result |
|---|---|---|---|---|
2024 | yes | no | not needed | True |
2000 | yes | yes | yes | True |
1900 | yes | yes | no | False |
Run the tests. All three pass. Now ask the next small question: "What other cases should I test?" A year like 2023 (not divisible by 4) is worth adding, and the answer is False.
Habits that keep you in control
Ask for one change at a time. Ten changes at once make it impossible to tell which one helped.
Read every line before you accept it. If you cannot explain a line, ask what it does.
Keep the test as the judge. Your confidence and the assistant's confidence are both worth less than a green run.
Write the test first when you can. It states your intent precisely.
When the test is not the problem
Most of the time a failing test points at code that is wrong. Sometimes it points at a test that is wrong, or at a requirement that is unclear. Imagine the third assertion had said is_leap_year(1900) == True. The code would have passed and the program would have been wrong. A test only checks what its author believed.
This is why working out the right answer by hand matters before you trust either side. For a date rule, look it up in a reliable reference. For your own program, write down in one sentence what a correct answer is, and then see whether the test says that sentence.
It also helps to ask the assistant for edge cases you have not tried: the smallest input, the largest, an empty one, one just either side of a boundary. For the leap year function, the century boundaries 1900, 2000 and 2100 are the interesting ones, and 2100 should be False because 2100 ÷ 400 = 5.25.
What it cannot do
It cannot see files you have not opened, so it may suggest changes that clash with code elsewhere.
It may fix the test instead of the code. Watch for changes that edit the expected value just to make a test pass.
It does not know your deadline, your style rules or your teacher's requirements unless you say them.
If you let it write everything, you will not learn the thing you are trying to learn.
Privacy and control
Your editor may show private paths, keys or customer data. Close or hide those before you share your screen with any assistant, and learn whether it looks only when asked.
DuckyHelper listens and looks only while the pill is open and for that answer, so the editor is not watched while you are idle. Doing work in other apps for you is in early access, and it's built to ask first before it sends a message or pays for anything.
Try it yourself
Pick a small function with one failing test. Say its purpose aloud in one sentence, ask for a hypothesis, make the smallest edit, run, and repeat. When it goes green, ask the assistant to explain why the fix works and see if you agree.
Frequently asked questions
Is this cheating on homework?
That depends on your class rules, so check them. Learning is served best if you can explain every line you submit.
What if the assistant and the test disagree?
Check the test. Sometimes the test is wrong, as with a mistyped expected value, so work out the right answer by hand first.
Get started
