Two weeks, four times a year, built around one question: how do you hand real work to an agent and trust what comes back?
You can already get a good answer out of a model. That is not what is slowing you down. What slows you down is everything around the answer: deciding what to hand over, bounding it so it cannot wander, and knowing the result is right without reading every line yourself.
That judgement is the job now, and it is the part no release note covers. Anthropic and OpenAI ship features. Nobody ships the decision about when a loop is worth building, and when you should just write the code.
Here is the shape of it. Generating code got roughly free. Checking it did not. So the constraint moved: every hour you save on writing arrives at the same queue, which is you, reading. Teams that have felt this describe it the same way each time. Throughput up, review load up more, and nobody quite able to say whether the codebase got better or just bigger.
You do not fix that with a faster model. You fix it by moving the checking off your desk, which means specifying so the work can be checked, constraining so most of it never needs to be, and building something that can say wrong without you in the room.
So this is not a tour of a tool. The Course does that, and it does it thoroughly. This is two weeks on the part that has no documentation.
Live hours are a submitted-question session rather than an open mic, which is what lets the room stay uncapped.
One cohort per quarter, and each one runs across two weeks. Not a rolling course you join whenever.
Live sessions spread across the run, plus lessons you work through on your own time between them.
You post questions in advance and upvote other people's. The most wanted ones get answered in the live hours.
Nobody is turned away to keep the room small. The submitted-question format is what makes an uncapped room work.
Six stages, in the order the work moves through them. Each one hands to the next, and the last one hands back to the first. That loop is the lifecycle the programme is named after, and it is the thing most agentic coding material skips straight past on its way to the tips.
How much spec to write, and when. A throwaway prototype and a payments change do not want the same document, and most of the pain comes from writing one when you needed the other. Then attacking your own spec with a second agent before a line is written, because the cheapest bug to fix is the one still in a sentence.
Where to put the guard rails so the agent cannot reach the bad outcome, rather than catching it afterwards. Pushing your standing instructions down into linters, types and static analysis, where a machine enforces them every run, instead of leaving them in prose the agent may or may not read this time.
The loop that runs the work: what starts it, what stops it, and what it does when a step fails. Back-pressure, so a failure reaches the thing that caused it instead of piling up for you at the end. And the honest version of when a loop is worth building at all, and when you should just write the code.
Verification is the bottleneck, and everything else you speed up runs into it. Splitting the work so one part produces and another part checks. Telling a real check from a rubber stamp. Fuzzing and property tests against agent output, which is where generated code fails differently from code you wrote.
Review at agent scale, when the volume of change is no longer something a person can read end to end. Separating the thing that proposes from the thing that judges, and why a model that agrees with you is worth less than one that does not.
The autonomy dial: how much you hand over, on what, and who is accountable when it ships. Decision surfaces, so the choices that need a human reach one and the rest do not. This is the stage almost nobody teaches, and it is the one that decides whether any of the five above survive contact with a team.
Deciding what the agent needs to know, getting it there, and keeping it across sessions. Including the failure almost everyone inflicts on themselves: several competing sources of truth in one context, which the model averages into something that follows none of them.
More than one agent on one problem: how the work is split, how results come back, and the cases where a second agent makes the answer worse rather than better.
Plus that quarter’s delta: what actually changed in the tools since the last cohort, and which of it is worth your attention. That part is different every time, which is why it is not in the grid above.
The class teaches the tools and the techniques, thoroughly, and it is maintained as those tools change. This is two weeks on the judgement around them: what to hand over, how to bound it, and how to know the result is right. That part has no documentation, and it is worth working through with other people rather than alone, which is why it runs as a cohort rather than sitting in a catalogue.
No, but you do need to already be shipping with an agent. This starts from the assumption that you can drive the tool and are stuck on everything around it. If you are not there yet, start with the class instead. It builds the foundation this assumes you have.
The live hours are recorded, and the lessons are yours to work through whenever suits you. The one thing you cannot catch up on is asking your own question, which is why questions are submitted in advance rather than shouted into a call: you can post yours, and upvote someone else's, without being in the room.
Nothing. It is an email address. The date and the price are announced to the waitlist before anywhere else, so the list is where you find out first, not where you get pushed.