Fractal Accelerator - Class 5 notes

Summary

Class 5 moved through four distinct parts: Andrew’s artifact walkthrough, Andrew’s summary of Gauntlet Loops, Liam’s walkthrough of ultracode, and a closing block on testing and credentials.

1. Andrew’s artifact walkthrough

Andrew opened the conversation he had used with an agent to build two study resources for students: a course glossary and an interactive practice test.

• Course glossary: a structured reference for the foundational AI and coding terms introduced in the class materials, including their definitions and relationships.
• Interactive practice test: a study tool that turned the glossary terms into multiple-choice questions and showed the relevant glossary card when a student answered incorrectly.

Andrew stepped through successive versions of the artifacts alongside the messages that produced them. The walkthrough begins around 1:07:00 in the video.

These were the main takeaways from Andrew’s walkthrough about how to work with an agent to produce a complex, polished artifact:

• Build a rich skeleton first. Start with the simplest representation that captures the essential structure, then add detail. Andrew began with a Markdown document outlining the glossary of terms before turning it into a website.
• Check intent and organization before polishing details. Andrew first evaluated whether the agent understood the intended product. He corrected definitions and parts of speech only after the overall structure was close.
• Share your emotions alongside concrete instructions. When the first artifact’s 196 terms felt overwhelming, he paired that reaction with specific requests for clustered sections, larger cards, definitions inside the cards, and printable groupings.
• Do not force the model to invent a change. When asking which terms should be removed, Andrew explicitly allowed the agent to answer “none.”
• Change the representation when work is difficult to evaluate. When the agent presented its recommendations as dense prose, Andrew asked it to rewrite its own response as headings and bulleted lists organized by glossary section so he could scan and compare the recommendations more easily.
• Build interfaces for giving feedback. Instead of routing every revision through chat, Andrew had the agent create an HTML redlining tool for editing text and marking cards or sections for removal.
• Separate content feedback from design feedback. Distinguish changes to the artifact’s information from changes to its visual structure and interaction so each kind of revision is easier to describe, apply, and verify.
• Store repeated procedures as skills. Andrew had previously asked the agent to identify which printer was the printer in the classroom and save the steps for using it. He then expanded that printing skill to turn raw Markdown and text files—which ordinarily print poorly—into the exact layout he preferred to read on paper. In this walkthrough, the skill let the agent format each glossary section as its own page, route the job to the correct printer, print only the largest page as a test, and use extremely high-contrast black-and-white output. When Andrew changes a printing preference, he updates the skill once so future sessions can follow it without requiring the entire setup to be explained again.
• Signpost a change in intent when taking the conversation in a new direction. Andrew and the agent had finished designing, printing, and deploying the glossary when Andrew shifted the same conversation toward a related but different artifact: a practice test. The glossary context was still useful, but the agent did not yet know the new design concept. Andrew explained why he wanted the test, clarified that it should help students study rather than trick them, and described the intended sequence: propose several effective question patterns, agree on them and save the design in test-design.md, then build the test one glossary section at a time. This gave the agent a clear boundary between the completed glossary task and the new test-building task, along with a map of what would happen next.
• Break large builds into independently reviewable sections. Design, test, and correct one part at a time instead of asking the model to produce the entire finished system in one pass.
• Keep the source of truth simple. Questions and glossary references remained in readable Markdown. A program generated the interactive test website from those files, including glossary-card explanations for incorrect answers.
• Design the project to survive compaction. Requirements, decisions, and current state should live in known files rather than only in the conversation, allowing an agent to recover after its context is summarized.

2. Andrew’s Gauntlet Loops summary

Andrew summarized Gauntlet Loops using Matt Shumer’s Claude-of-Duty project: a single prompt that asked Claude Code to build a first-person shooter comparable to a recent Call of Duty game. The run lasted about 24 hours, consumed roughly two billion tokens, and produced a playable game from the unchanged prompt. This section begins around 2:06:00 in the video.

The prompt told the lead agent to divide the project into independently improvable pieces, fan work out to subagents, and assign a separate harsh critic to inspect each result. The critic compared the real output with an external quality bar, using blind side-by-side evaluation where possible, identified the largest remaining gap, and sent that piece back through another round. The /loop instruction kept the process running, while “ultracode” triggered a dynamic workflow in which the lead agent designed and managed the team.

Andrew contrasted this with his earlier glossary workflow. In the glossary session, he supplied the structure and refined it through a close back-and-forth. In the Gauntlet run, he let the agent establish its own internal direction over many hours, then used meta-agents to review the run’s history, find repeated mistakes and wasted effort, and suggest tests or developer tools that would improve the next iteration. Games were used as the example because they require many interdependent assets and systems, but the same loop can be applied to other ambitious builds.

3. Liam’s ultracode walkthrough

Liam showed how to start ultracode in Claude Code, the Claude desktop app, and Codex. In Claude Code, students could type /effort and move the effort slider to ultracode, or include “ultracode” in the prompt. In Codex, they could choose the Ultra effort setting from the model selector. The walkthrough begins around 2:23:00 in the video.

For the live example, Liam asked each tool to make a disco-themed Space Invaders game playable in the terminal. The lead agent created its own team and workflow: three agents developed design concepts in parallel, other agents implemented the game, reviewers inspected it, and later agents fixed and verified problems. Liam opened one of the child-agent prompts to show Claude assigning a specific role—theme and copy designer—and asking that agent to create the game’s disco fiction and text. The phases and roles were generated for this particular project rather than selected from a fixed template.

Liam distinguished an ultracode workflow from manually requesting subagents. A simple subagent request can fan out several independent tasks and return their answers, but the parent does not necessarily design roles or manage a continuing process. In ultracode, the parent writes and runs an orchestration workflow, prompts specialized agents, combines their work, and coordinates design, implementation, review, repair, and verification.

He also demonstrated /goal, which attaches an observable outcome to the session and allows the agent to continue across multiple workflows until the goal condition is met. Without a persistent goal, a run may stop earlier than expected.

Liam noted that cost and duration depend on scope: ultracode can parallelize a bounded research task without running all day, while a large open-ended build can consume substantial time and tokens.

Students then started their own ultracode runs in Claude or Codex. They could use an ambitious existing project, begin a new project that seemed too large to finish in one sitting, or try a smaller prompt with room for many parallel approaches. The class left the runs active so students could inspect how each parent agent decomposed the work and managed its own process.

4. End-of-class testing and credentialing

The final block turned toward testing what students had learned. Students were given a glossary of foundational computing terms and techniques, along with a practice test designed to resemble the optional exam. The practice test allowed students to move between sections, retry questions, and see terms in context.

The instructor emphasized that vocabulary is not the main path to useful results. Shared language is valuable because it helps students understand documentation, write more precisely, and communicate with agents. The practice test turns that language into something students can actively retrieve and use.

The credentialing structure announced in class was:

• Training certificate: awarded for participation in the class.
• Graduation with distinction: awarded when the oral assessment showed that a student had practiced and implemented the exercises and homework.
• Graduation with honors: distinction plus an exam score of 85% or higher.

The oral assessment and proctored exam form a single evaluation, available in person or remotely after the end of class.

The practice test is available at fractalaccelerator.com/class/practice-test.