Fractal Accelerator - Class 6 notes

Summary

Class 6 was the final in-person session. It covered five parts: a game about what it is like to be an agent inside a file system, how to keep up with the frontier of AI, the compounding process, Andrew’s preferred software development process, and how he built the class game.

The class used two handouts: the Software Development 101 sheet and the class overview document, a companion to the glossary from Class 5 that lists every concept the class intended to teach, with checkboxes for the work students should have done between classes.

1. Context Dungeon: what it is like to be Claude

The class opened with a speed run of Context Dungeon, a game linked from the student portal. Each student played a subagent racing to complete twelve clerical tasks by navigating a file system, with every file opened taking up space in a limited context window.

The debrief covered the lessons behind the game:

• It is hard to be Claude. The agent has no magical knowledge of your files. It has to search, and every file it reads competes for space in context.
• Organize your files. A well-organized file system and a README or index that tells the agent where everything is save minutes on every task. Otherwise, the agent has to search on every request.
• Give the agent useful tools. The game had no Control-F. Claude has grep, and could also have ranked semantic search over your files. This is the “bitter lesson”: tools like search that reduce complexity by orders of magnitude always win.
• Put routing information in AGENTS.md, everything else in READMEs. Anything relevant to every request, like where things live, belongs in the always-loaded file. Detail that only matters sometimes belongs in a README the agent reads on demand, so it does not distract the model.
• Context rots. If you ran the setup prompt weeks ago, your AGENTS.md is probably out of date. Read your README files periodically to see whether they help the agent or distract it. You can schedule an agent to review and clean them up with fresh context.
• Diagnose slow or unreliable tasks by putting yourself in Claude’s shoes. If quality degrades or tasks take a long time, it is often because the chain of tools, APIs, and file structures the agent has to navigate before it can start is too long. Build the environment around the job.

2. Following the frontier

New tools and models appear every week. Liam demonstrated GrokBot, adopted that week: a group chat of agents that each have their own cloud computer.

Two pages on the site help you find useful tools without treating any one source as gospel:

• Following the Frontier in the reference library, a guide to deciding which sources to trust and a list of people who show their work. Examples: Simon Willison, whose blog covers nearly everything that happens in AI and whose “pelican on a bicycle” test benchmarks every new model; Every, which writes for non-engineers doing knowledge work with AI; and Maggie Appleton, whose barefoot developers essay was a reading at the start of the class. You do not need to read everything. Give these URLs to an agent and ask what came out this week that matters for your work.
• The frontier feed on the site, an automated daily summary of Liam’s Twitter bookmarks for anyone who wants to follow the field without using Twitter.

Students ran the prompt on the Following the Frontier page, which looks at your files and projects and recommends sources relevant to your work. Takeaways from the debrief:

• Ask the agent to cite everything so you can check it, and give it a stronger web search tool such as Exa if the built-in search is finding only the obvious names.
• The results skewed toward generic “top AI people.” That reflects a real gap: most writing about AI agents comes from software engineering. Students in other industries should write about their own experience, because little has been written about using AI agents in those industries.

3. Compounding

The compounding guide in the reference library is based on Every’s compound engineering idea: working with agents gives you both the output and a cheap way to document what you learned in a conversation.

After each piece of work, have the agent review it and use what it learned to make future work easier. Several students had already built versions of this, such as agents that summarize a project’s progress for teammates. This helps you avoid building something large and then losing track of how it works.

Students ran the “learn from your past conversations” prompt from the guide against whichever tool had the most context on them. It looks for patterns, including repeated actions and mistakes, and proposes lasting changes. Observations from the debrief:

• It often gives you feedback on how you give feedback. That can feel uncomfortable, but it helps you see your blind spots.
• Not every suggestion is worth implementing. If something seems like a chore that would not help, skip it. It reliably finds habits that keep you stuck.
• “Where is that chat” and “what is the latest state of this project” are the most common problems it finds, and agent memory is the usual fix.
• Improving your process helps, but it can become all you do. Running this prompt once a week is a good balance.

4. Andrew’s software development process

After a break, Andrew walked through the Software Development 101 handout, which describes his own process and covers most work.

Get good at one-shotting things before professional software engineering, because cheap and fast always wins. Once you have software you like, you need a process for maintaining and changing it for years without fear of breaking it.

Checkpoint, build, test

The second section of the handout covers checkpoint, build, test. Use all three steps every time you change existing software.

• Checkpoint means save the current state so you can always return to it. Git is the version control software; GitHub is the cloud service that stores Git repositories, like Google Drive for code. You do not need the terminology. Saying “checkpoint the reader app” is enough, and you can add guidance for the commit message, such as a version number and a feature list, to make history easier to navigate later.
• Build is the feature itself, with design guidance in the same prompt.
• Test means running automated behavioral tests, for example in headless Chrome, to check that the change works now and keeps working.

Put all three steps into one prompt. With a checkpoint in place, you can let the agent build, test, and deploy without watching over it, then revert if the result is wrong.

Two related ideas came up in questions:

• Your Git history is data like any other. You can ask the agent to visualize the whole history in your browser or build a switcher between versions.
• When prototyping something new, none of this matters much. When the stakes are high and you are changing software you depend on, do all three every time.

Grill, spec, tickets, implement, review

The first section of the handout is the fuller process, adapted from Matt Pocock’s open-source engineering skills, which you can install into Claude Code or Codex and ask the agent to teach you. The process helps you work alongside an engineering team or let other people’s agents work with yours.

• Grill. Get everything in your head about the problem into the agent’s context: goals, constraints, edge cases, what done means. It replaces the meeting.
• Spec. Turn that into a written skeleton. Andrew combines grill and spec into one prompt: he talks through the idea by voice, then asks for a minimal bullet-point design skeleton with no prose and no explanations, and explicitly says not to build yet.
• Tickets. Break a large task into pieces that independent agents can work on in parallel. Pocock’s skill defines “seams,” boundaries between tickets, so agents can work at the same time.
• Implement. Checkpoint, build, test, optionally with test-driven development, where the tests are written first and the system is built to satisfy them. Pocock adds a fourth step, review, to every cycle; you can too.
• Review. Review the diff between the current code and a fixed checkpoint in two ways: does the code follow the repo’s documented standards, and does it implement the spec? Both reviewers run as parallel subagents with separate context so they do not bias each other, the same reason you want an independent human reviewer. The skill then combines their findings and repeats the process.

Match the process to the stakes. A toy does not need the full engineering process: ask for a design skeleton of one concrete page showing the experience, with no engine or architecture yet. Once a demo proves the idea is fun, you can throw it away and design the real system.

Rewrites, smells, and anti-patterns

• When do you need a rewrite? When the current system cannot meet a requirement of the specification no matter how you prompt or tune it. When do you want one? Often out of frustration with the current code, which on its own is not a reason to rewrite. Tests are what make a rewrite safe: if the behavioral tests still pass, the behavior stays the same even though the architecture changed. Watch for reward hacking, where the new system meets the new requirement by dropping everything else it used to do. With agents you can also try a rewrite and improvements to the existing system in parallel instead of debating.
• Smells are the engineering word for the feeling that something is off before you can say why. Anti-patterns are patterns that tend to spread but should not, such as all the code in one file, which makes parallel work impossible. Whether something is a pattern or an anti-pattern depends on context.
• Reading skills like Pocock’s is one of the best ways to learn what good engineers consider good process, because the skills put their judgment into words.

Five testing prompts

Testing and code review are the two things Andrew most wants students to take away. The handout gives five prompts he uses constantly:

1. Add behavioral tests “to ensure all important behaviors always work now and forever.” Behavioral means testing what the software does, not properties of its code.
2. Test in a real browser using headless Chrome, so the tests run automatically over the real DOM without the agent driving a visible window by hand.
3. Optimize the tests “using best practices so they run faster and more efficiently,” for when the suite is slow because the agent added sleeps throughout it.
4. Adversarial testing. “What are all the likely ways our app might break or not work? Test against all those cases in advance.” Find the failure modes before strangers on the internet do.
5. Add tests for bugs. When you hit a bug, “add a test which will replicate it and guard against regressions, and document what regression we are defending against so we do not delete this test.” Bugs recur, especially across rewrites.

A good first exercise on any project you maintain: checkpoint it, add behavioral tests, then run the adversarial prompt and see what happens. If nothing you have built feels complicated enough, run a grilling session on what custom software could replace things you currently do by hand.

5. How Context Dungeon was actually built

Andrew closed the section by showing the process he actually ran to build the game. In practice he blends everything together: build something he likes, and only once it needs to survive, because it might break and cause problems later, does he bring in the engineering process. The industry calls this agile. Make the thing first, without worrying much about process, because what matters most is that the thing exists and works. Once that is true, you can always build a process around it, re-engineer it, or rewrite it.

The steps, as they appeared in his messages:

• Context dump, then ask for a design skeleton. He talks through the idea by voice, then asks for a design skeleton, his version of a specification: bullet points in the browser laying out every aspect of the task. He asks for absolutely minimal bullets and no prose. A design skeleton is for skimming, not reading. He would have it speak in code if he could, but he reads English, so bullets are the next best thing.
• Add what the skeleton missed. The skeleton had not considered the music, so he added the song he wanted.
• Hand it the whole process. He set the model to ultracode and told it: “Create an ultracode process for yourself which will guarantee completion and working behavior of every aspect of the game until it is fully ready to play and ship. Don’t stop until you’re done.” That is the engineering process from the handout, delegated. The agent planned it out itself: study the audio file, write a spec checklist with every mechanic that must pass, fan out content generation for the mock file system, build the engine while that runs, then loop headless play tests and a multi-agent review until every spec item is verified.
• Judge by using it, not by reading about it. When the agent reported that the game was built, verified, and shipped, he did not read the report. He opened the game and played it.
• Checkpoint, build, test, in one message. His reply: commit the game as it is as a functional MVP (the checkpoint); then a list of features, showing the file location under the context display, left-aligning a button, adding a jukebox in the bottom right corner with a note on how to make room for it; then “create behavioral tests for all this stuff, so you’re sure it will work as intended”; then a music credit for the song’s creator on the title screen. The process shows up in the message itself: checkpoint, build what I want, add tests so it keeps working.
• Keep going the same way. After that he just kept sending more: the title screen text was overlapping a wall, and so on. That was the whole process behind the game the class played.

Andrew said this is the best process he knows and he would not add more to it, even for a professional engineer. More process does not by itself get better outcomes. Every engineer ends up with a different process, and so will you.