How to Run Claude Code on Complex Projects

TL;DR

Use a long-running agent harness to divide a complex application into manageable features, implement them sequentially, and perform regression testing without constant supervision. Compared with a normal Claude Code workflow using the same prompt and model, this approach produced a more complete application with working card manipulation, editable prompts, project controls, theme options, and reference-image support.

Transcript

Welcome back and a happy new year. Now, I'm convinced that longunning agents are the future of Agentic Coding and Vibe Coding. And in this video, I'll prove that to you. I'm going to show you two projects that have three things in common. They were both built using Clawed Code. I sent them each the exact same prompt. And finally, I didn't interfere... Read More

Key Insights

• A single context window is insufficient for some massive application builds because implementation can exceed its capacity, trigger repeated conversation compaction, and lose important requirements. In the demonstrated normal workflow, requested features such as theme support, editable prompts, and functional card manipulation were missing.
• A long-running agent harness works by splitting a large requirement into smaller features, implementing them one by one, and incorporating regression testing. It can continue for hours or days, allowing a complex project to progress without requiring the user to supervise every implementation phase.
• Manual phase coordination creates continuity risks because each cleared context can leave the next session without a complete understanding of earlier work. The transcript compares this process to developers working separate shifts, where later work can duplicate code or introduce bugs that break previous functionality.
• The comparison used the same detailed prompt and Opus 4.5 in thinking mode for both projects. The normal Claude Code CLI workflow produced a basic interface, while the long-running approach delivered more requested features and additional project controls that were not explicitly requested.
• The normal implementation reported successful assistant actions without updating the visible application state. Requests to change Zapier to make.com or remove an intro card appeared successful in the conversation, but the cards remained unchanged even after the page was refreshed.
• The long-running implementation connected assistant actions to the interface correctly. It changed a card from ten hours to five minutes, displayed an edited badge, preserved the previous version in a history view, and removed another card when asked through the assistant.
• The improved project included light and dark modes, editable system prompts for hooks, intros, titles, and thumbnails, plus project filtering and controls to delete, edit, duplicate, and open projects. It also displayed the user's position in the workflow and summarized the selected topic.
• Nano Banana reference-image support emerged during planning after the agent researched the model's capabilities and asked whether reference images should be accepted. The creator approved the idea and placed an existing thumbnail template in the project's public thumbnails template folder for use as a visual reference.

Questions & Answers

Q: Why does a normal Claude Code workflow struggle with large projects?

A normal workflow can struggle when a massive implementation must fit within a single context window. In the demonstrated project, the agent repeatedly compacted the conversation after exceeding that window, which caused important requirements to be lost. The resulting application had a basic interface, but requested features such as light and dark modes, editable system prompts, image generation, and reliable assistant-driven card changes were missing or incomplete.

Q: How does a long-running agent harness handle complex coding projects?

A long-running agent harness divides a large requirement into smaller features, implements those features one at a time, and includes regression testing. The harness can operate for hours or even days without requiring constant user intervention. This structure allows the agent to work through a substantial feature list while retaining project continuity and checking that new changes do not break functionality completed during earlier phases.

Q: What was different between the two Claude Code project tests?

Both projects received the same detailed prompt and used Opus 4.5 in thinking mode, but they followed different execution methods. The first used the normal Claude Code CLI process with planning followed by implementation in one continuing context. The second used a long-running harness. The harness version delivered a substantially more polished interface, more requested functionality, working assistant actions, additional project controls, and reference-image support.

Q: Which requested features failed in the normal Claude Code build?

The normal build lacked the specified light and dark modes and provided no visible way to edit the system prompts used by the hooks, intros, titles, and thumbnail agents. Assistant requests claimed to change or remove cards, but the visible cards did not update, even after refreshes. Thumbnail generation returned only a description instead of an image, and completing a project returned to the home screen without a summary.

Q: How did the improved AI assistant manipulate content cards?

The improved assistant changed application data and immediately reflected the result in the interface. When asked to revise a hook from spending ten hours to spending five minutes, it updated the card and added an edited badge. A history control exposed the card's earlier version. When asked to remove card five, the assistant removed it from the displayed list, demonstrating functional integration between the conversation and application state.

Q: What project management features did the long-running build add?

The long-running build added filters for different project statuses and controls that appeared when hovering over a project card. These controls allowed the user to delete, edit, duplicate, or open a project. The delete action worked during the demonstration. Inside a project, the interface displayed the current position in the creation process, summarized the topic, and kept the AI assistant available on the right side.

Q: How were Nano Banana reference images incorporated into thumbnail generation?

During planning, the agent researched Nano Banana and asked whether the application should let users provide reference images. The creator accepted the proposal because the model could generate new images and edit supplied images. A frequently used thumbnail template containing the creator was then uploaded into the project's public thumbnails template folder, allowing the application to use that existing visual asset as a reference for thumbnail designs.

Q: Why is manual coordination across implementation phases risky?

Manual coordination requires the user to initiate each phase, clear the context window, and instruct the agent to continue with the next phase. The transcript compares this to developers working separate shifts without full knowledge of earlier work. A later session can create duplicate code or introduce bugs that damage completed features. Repeating this process across twenty or fifty phases also forces the user to babysit the implementation.

Summary & Key Takeaways

• A normal Claude Code workflow used one detailed prompt, planning mode, and Opus 4.5 in thinking mode to build a content-creation application. The result included basic hooks, intros, titles, and assistant functions, but several requested capabilities were absent or broken after the project exceeded the available context window.

• The long-running harness divided the large requirement into smaller features, implemented them individually, and included regression testing. This reduced the need for manual coordination between phases. With the same prompt and model, it produced a more polished application containing theme controls, editable system prompts, project management actions, and process tracking.

• The stronger application allowed users to generate, select, copy, edit, add, regenerate, and remove content cards. Assistant-requested edits appeared directly in the interface, and card history preserved previous versions. The planning process also researched Nano Banana capabilities and proposed reference-image support for generating thumbnails from an uploaded template.

• Key Insights framework harness testing

• Key Insights practice context engineering