55 AI: Delegate the full problem
You now hold three separate skills. You can specify a function by writing its contract as tests before any code exists. You can read a function the assistant produced and judge it against a short list of questions, refusing to believe it until the machine agrees. And you can take a task larger than one function, break it into named and testable pieces, and write that plan down before you prompt for anything. The finale is where these three stop being separate exercises and become one continuous way of working, applied to a task that is deliberately larger than anything you could sit down and write on your own. That last point is not an accident or a cruelty; it is the entire purpose of the exercise. The role you are stepping into this week is the one the whole course has been climbing toward, which is to delegate a real job to the assistant and remain completely responsible for the result.
Be exact about what beyond your unaided reach actually means, because it is easy to misread it as a demand that you suddenly become a better programmer than you are. It is the opposite. You are not expected to be able to write the finale from a blank page. You are expected to be able to produce it, correct and understood, by driving the assistant through a plan you designed and by verifying every piece it hands back. The gap between those two things, between writing a program yourself and producing a correct program you did not type, is the gap this course exists to close. A professional programmer would write the finale unaided. You will instead decompose it, specify it, delegate the typing of each piece, and check everything, and if you do that well the finished program will be just as correct as the professional’s, and you will understand it just as well, even though you could not have produced it keystroke by keystroke. That is a considerable and useful ability, and it is the one you are being asked to demonstrate.
The way you do it is simply the full loop assembled from the parts you already have, run once for each piece of the plan. You begin, before prompting anything, by decomposing the task into named functions with stated inputs and outputs, exactly as you practiced, so that you are holding a plan made of small pieces each of which you could read, test, and understand on its own. Then you take the pieces in dependency order, and for each one you run a short cycle. You write its contract as one or a few tests, seeded from the example in your plan and stiffened with the awkward cases you have learned to fear. You prompt the assistant for that one function, giving it only what it needs, which is the function’s purpose, its inputs and outputs, and the tests it must satisfy. You read what it returns against your judging questions. You run the tests and let the machine deliver the verdict. If the tests pass, that piece is done and you move to the next, building it on top of a piece you have already proven. If the tests fail, you do not start over and you do not despair; you write a specific change request, naming the failing input, the wrong output, the right output, and the reason as far as you can see it, and you send it back and run the tests again. Nothing in that cycle is new. The only new thing is that you are running it many times, on a task whose finished form you could not have written, and watching a program you understand assemble itself out of pieces you have each checked.
The iteration inside a single piece deserves a word, because it is where students most often lose their footing. When a piece fails and you send the assistant a specific change request, the loop should converge: the next version should be closer, and after one or two rounds the tests should pass. If instead the assistant keeps failing in the same way, or fixes your named case while breaking another, that is not a reason to keep hammering the same prompt harder. It is a signal, and it usually means one of two things. Either your specification is wrong or incomplete, so the assistant is optimizing for a target you did not actually mean, in which case you fix the tests and not the code. Or the piece is small enough and you now understand it well enough that you should simply write it yourself, because you have reached the point where delegating costs more than doing. Knowing when to stop asking the assistant and take the keyboard back is part of the skill, not a failure of it. The assistant is there to save you effort on pieces you have specified, not to be argued with indefinitely about a piece you could finish in five minutes.
Two things about verification change scale in the finale and you should meet them deliberately. The first is that the project comes with a suite of tests already written, the same kind you have been running through the check widget, and it is tempting to treat passing that suite as the finish line. It is not. The provided tests are a floor, not a ceiling. They are the conditions the graders and the author knew to check, and passing them is necessary, but it is not proof, because no suite tests every input and the assistant is expert at producing code that satisfies the visible tests while failing the invisible ones. So you add your own tests, especially the nasty cases you have learned to distrust, and you treat the provided suite as the beginning of your checking rather than the end of it. The second is that passing tests, even your own, is still necessary rather than sufficient. A green result tells you the code is correct on the cases you thought of. It cannot tell you the code is correct on the cases you did not. The backstop for everything the tests miss is your own understanding of the pieces, which is why the rule that you never accept code you cannot read matters even more here than it did on a single function. If a function passes every test but you cannot explain why it works, you have not finished with it, because the day it meets an input none of your tests covered, your understanding is the only thing standing between a wrong answer and a wrong result you publish.
That last point is really about responsibility, and responsibility is the part of delegation that does not transfer. You will hand pieces of typing to the assistant, and that is fine, but you cannot hand it the ownership of the result. When you submit the finale, you are submitting it, not the assistant, and you must be able to stand behind every function in it and explain what it does and why it is correct. If a reviewer, or a marker, or your future self points at a function and asks how it works, the answer the AI wrote it is not an answer, it is a confession that you delegated the thinking along with the typing. The whole architecture of the course, the specifying and the judging and the planning, exists so that you can use the assistant heavily and still own the outcome completely. Delegation done well is not the absence of responsibility. It is responsibility exercised through verification instead of through typing.
To make your verification visible, both to yourself and for assessment, you keep a prompt journal alongside the finale as you build it. Where the weekly logbook is a broad reflection, the prompt journal is narrow and practical: a running record, piece by piece, of what you asked the assistant for, where its answer was wrong, how you caught it, and what you did about it. Keeping it costs a little effort in the moment and pays back twice. It forces you to actually notice the failures rather than skimming past a bug you half saw, and by the end of the project it is a concrete record of your own judgment at work, which is exactly the thing the finale is meant to demonstrate. A finale that runs is worth less, in this course, than a finale that runs and comes with a frank account of the half dozen places the assistant got it wrong and how you knew.
You will do most of this on the real project, so the exercises here are small and meant to sharpen particular moves in the loop.
Exercise 55-1
Run one full cycle on one piece, in the order that makes it safe. Before you prompt for anything, write the acceptance criteria for a single function from your plan: what it must return for which inputs, including the awkward cases, in a form the machine can check. Then prompt the assistant for that function, giving it the purpose, the signature, and nothing you have not decided. Read what comes back. Run the criteria. The thing to notice is that you wrote the criteria while you still had no code in front of you to anchor your idea of what correct meant, which is the only condition under which delegating a whole piece is anything other than hoping.
Exercise 55-2
Take a single function from your plan, prompt the assistant for it, and when its first attempt fails one of your tests, write the change request you would send back, containing the failing input, the wrong output, the correct output, and the reason. Notice how much of that you already knew from having written the test first. Send it. If the second version passes, the loop converged; if the third does not, stop, and go to the next exercise.
Exercise 55-3
Take the keyboard back. Find a piece where the loop did not converge in two rounds, or where you can already see the answer, and write it yourself. Time both if you can. The skill this exercise trains is not programming, it is the judgment about when delegating has stopped paying, and it is a skill in exactly the same sense that specifying and judging are. An assistant argued with for twenty minutes over a function you could have typed in five is not saving you anything, and noticing that quickly is part of using it well.
Exercise 55-4
Take a function that has just passed the provided tests and write one more test of your own, a nasty case the provided suite did not include, and run it. If it also passes, you have strengthened the contract. If it fails, you have just caught a bug that would otherwise have shipped, and you have proved to yourself that the provided suite was a floor and not a ceiling.
Exercise 55-5
Finally, the exercise that decides whether you may keep the badge. Pick the function in your finale that you delegated most heavily, the one you are least sure you could have written yourself, and write one paragraph explaining how it works, in your own words, with the assistant closed. Not what it does, which you know from its tests, but how it does it, line by line. If you cannot, that function is not finished, whatever its tests say, because you cannot own a result you cannot explain. Do the reading now and write the paragraph again. This is what it means to say that delegation transfers the typing and not the responsibility.
Exercise 55-6
Write one prompt journal entry for a piece you built, recording where the assistant was wrong and how the machine, or your reading, revealed it.
For your logbook this week, step back from the individual pieces and describe the experience of producing something you could not have written unaided: which part of the loop, the planning, the specifying, the judging, or the iterating, did the most work in making the task possible, and name one function in your finale that you are confident you could now explain in full to someone else, and one that you are not yet sure you could, because the second kind is where your remaining work is.