Blog/Week 1 of Cohort 4, and We’ve Already Seen a Different Way to Build

Week 1 of Cohort 4, and We’ve Already Seen a Different Way to Build

Week 1 of Cohort 4, and We’ve Already Seen a Different Way to Build

Cohort 4 of Gauntlet started this Monday. Within three days, we were already seeing things we hadn’t seen in prior cohorts.

One of them came from how Ian Zepp structured his model stack.

He uses Claude Opus for high-level reasoning, design interpretation, and specification writing. He uses Codex 5.3 for implementation and detailed engineering work. In his workflow, Claude defines the vision and structure; Codex executes against it. The handoff between the two is intentional, not accidental.

Week 1 of the program takes place during the remote phase. The assignment is to rebuild a production-grade, real-time collaborative whiteboard: infinite canvas, multiplayer cursors, low-latency updates, AI-first workflows throughout. The goal is not cosmetic polish. It is to learn how to build substantial systems with coding agents and structured iteration from day one.

Ian described the constraint publicly on X:

“You have 24 max to build a functional, deployed, performant multi-user collab whiteboard, from scratch, using only wits, bits, and an AI.”

Every cohort approaches this differently. Some engineers focus on infrastructure depth. Others push performance or synchronization. This week, we saw something new on the interface side.

By day three, Ian shared a screenshot of his project in Slack. It stood out immediately. The typography was cohesive. The layout felt deliberate. The visual theme looked designed rather than prompted.

Ian’s Week 1 whiteboard UI

Watch the product in action (as seen in night mode).

Ian’s background includes early Linux contributions, enterprise systems, startups, and a multi-year break from tech before returning through AI. What stood out in Week 1, though, was not tenure. It was process discipline.

Instead of prompting a model to “improve the UI,” Ian started with reference material. He found a design on X/Twitter with a distinct visual style. He took a screenshot and gave it to Claude with a specific instruction: generate a design specification based on this image. Break down typography, spacing rules, layout structure, color palette, and theme.

In Slack, he described the exact workflow:

“I literally took a screenshot of something I like, gave it to Claude Desktop, and said ‘extract the design elements as design.md file.’ Then I gave the design.md to Claude Code and said ‘make me a mockup.’”

Claude produced a structured design document.

That document became the contract. Ian passed the spec into Claude Code and asked it to generate a mockup aligned to the document. From there, he iterated conversationally. Adjust spacing. Shift alignment. Modify color. Rebuild. Review. Repeat.

The visual language itself came from earlier experimentation. Ian mentioned that he had previously explored a “dinosaur field-research design/theme” inspired by 1970s journals, and reused that mockup as the foundation for this whiteboard interface, adapting it to collaborative UI elements.

He does not manually edit front-end code. He treats the model as the implementation layer and focuses on direction and evaluation.

The spec sheet is the bridge between taste and execution. Claude translates a visual reference into structured language. Codex translates that structure into working code. Changes are made through conversation, not direct edits.

There is a broader technical shift embedded in this. Multimodal models can now interpret screenshots into implementation-ready documentation with enough fidelity to guide real builds. That changes how quickly an engineer can move from inspiration to interface.

We will continue sharing patterns like this as Cohort 4 progresses: how engineers are structuring model handoffs, how they are managing iteration loops, and what workflows are emerging under real constraints.