Junie /demo builds the app and drives the UI so the reviewer watches instead of clicking

The first run in a repository costs more than the later ones. Junie analyses the project, proposes a build and launch plan, and writes the configuration itself once you approve the plan ^[2]. Docker has to be running before any of that happens ^[2]. Those generated files are the input to every later run, so JetBrains tells you to read them before the first /demo ^[2].

The request field is where the work moves. The example in the post is a three-part instruction: reset the sample data, select PB-101 and PB-102 and mark them Done, check that Open drops from 3 to 1 and Done rises from 1 to 3, then reload and verify both issues are still Done ^[4]. "A request with an expected result gives the run a clear target," the post says, and it contrasts that with "Check the feature", which leaves more room for interpretation than naming the action, the expected state, and the condition that should survive a reload ^[5]. That is a test case written in prose. Someone still has to know that the Open counter should read 1.

The HTML report collects the request, the result, the video and the screenshots, and lets you inspect which steps ran and which checks passed, failed, or remained incomplete ^[8]. JetBrains keeps the last call with the person: "You decide whether the change is ready to ship" ^[14]. The company says it is also experimenting with the same output in Junie Live, its Slack agent, to answer suitable feature questions with a demonstration ^[15].

The narration is generated. During post-processing a model examines the captured screenshots, identifies the scenarios, and writes the explanatory slides that are then assembled into the final video ^[6]. Subtitles can be switched on or off in the player, and voice-over may arrive in a later update ^[7].

JetBrains reports running the demo agent on more than 1,500 unique pull requests in its own agent repository, producing over 2,100 videos ^[9]. Divide one by the other and you get about 1.4 videos per pull request ^[16]. Both figures are floors, so treat that as approximate; a branch that gets pushed to twice gets demoed twice. Across its internal release branches the company counts more than 1,300 smoke tests ^[12].

For those counts to mean anything in another repository, two things have to hold: the app has to build and launch under Docker from a plan the agent wrote, and the change has to put something on a screen. A backend change can sometimes be exercised through an existing Swagger UI ^[10]. "The value depends on what the run can actually observe," the post says ^[11].

The post does not report review time saved or defects caught; the numbers it gives are counts of runs ^[17].