I started using T3 Code for a very practical reason: the computer in front of me isn’t always the best computer for the work I need to do. My everyday company computer is a Lenovo Legion with an Intel i9-14900HX, 32 GB of RAM, and an RTX 4070 Laptop GPU. It’s a capable machine, but it still has limits. When I’m running an application, compiling projects, reviewing UI, keeping several coding sessions open, and working on multiple things at once, the Legion can quickly become the bottleneck. At the same time, I have legitimate access to other computers that are often sitting idle. At the company, there’s an iMac with only 12 GB of RAM. It’s useful when I need macOS, but it isn’t the machine I would choose for heavier parallel workloads. We also have a dedicated Windows GPU workstation with 64 GB of RAM and a Radeon RX 7600 XT with 16 GB of VRAM. That machine has considerably more headroom for large builds, multiple simultaneous tasks, local models, and GPU-intensive work—especially at night, when nobody else is using it. At home, I also have my personal Linux machine. It has its own role: persistent services, Linux-native tooling, background processes, and projects that make more sense in a Linux environment. Before T3, these felt like separate computers. Every machine had its own files, terminals, dependencies, running processes, and unfinished work. Moving between them meant rebuilding context, copying things around, or trying to make one computer handle everything. T3 Code—and especially T3 Connect—changed that for me. Now I can sit at the Legion and connect to whichever environment makes the most sense for the task. The repository, terminal, dependencies, Git state, and running processes remain on the machine actually doing the work. I don’t need to move the entire project just because I moved to a different desk or opened a different laptop. This means I can review an application’s UI from the Legion while the application itself runs on the 64 GB GPU workstation. I can leave a build or a long-running task working there while I continue something else on my Linux machine. If I need macOS, I can move to the iMac environment without disrupting everything else.

Have been looking at the documentation for this, I think I have myself a weekend side project. The framework has interesting tools. Amongst them is evaluation as well, I think its trying to bring engineering disipline to skill creation. What I am thinking is can we create an iterative workflow for building agent skills: draft a skill, evaluate it with SkillEvaluator (especially the live Skill Lift measurements), then use the results to improve it. Loop until the skill is high-quality, safe, and demonstrably helpful. Maybe create a workflow for Atomic. Wonder if we could use DSPy to optimize the prompt, could we use SkillEvaluator to generate enough synthetic, high quality eval data... Mind just goes. Just wanted to share https://docs.nvidia.com/skills/skillevaluator/quickstart

So many wonderful insights today during the builder group session. My three favourite takeaways were: - Hearing from everyone on their specific challenges and blockers, and what they're trying - Ship faster - get feedback quickly - Logging and flow - Norin and Ray shared some great ideas around using logging to nail down what the issues are, and using Atomic with carefully scoped tickets or build sessions so that the agents don't get overwhelmed and go off the rails. Thanks again, Ray, for organizing this - it was really great to jump on and hear about how other people are building, and how they are overcoming their unique obstacles. I can't wait for the next one!

I built this project to test Grok Bot and Atomic. I believe I went overboard lol still this is a good sample case of my weaknesses. It is far from over. It does not auto update yet and I'm still working on it. https://battle-harnesses.vercel.app/ 1. What are you trying to make happen? I want to use one real project, **Battle Harnesses**, to learn how a senior developer would frame and organize a software project from the beginning. Battle Harnesses is intended to be a public guide to AI coding harnesses. Behind the website, there is a private research system that gathers and evaluates source-backed information about the products. The website then publishes a useful view of that research. There is also a separate public pack containing only the material that is safe and appropriate to distribute. For this session, I am not mainly asking for help fixing the current repository. I want to reconstruct how I should have thought about the project before building it: - how to turn the product idea into clear system boundaries; - how to choose the smallest useful version; - how to define sources of truth and the data flow; - how to separate private research, public product output, and local AI working memory; - how to decide what belongs in GitHub and what must remain local; - how to define tests and proof before delegating work to AI agents. I would like to leave with a simple project-start method that I can reuse on future projects. 2. What have you tried already? I began by researching the product landscape and building the website with AI coding agents. Over time, the project developed several layers: - source-backed research ledgers and product dossiers; - generated website data; - a React/Vite website with product, comparison, and guidance views; - a private development repository; - a separate public distribution pack; - a local-only `AI_OS` layer intended to preserve decisions, current state, and instructions for AI agents.

First, I’m looking forward to connecting with everyone joining! Here’s my focus: 1. What are you trying to make happen? Getting my complex next.js/react project to the last 30%. Most importantly getting proper QA after autonomous builds with many PR merges and a whole lot of agents doing side projects, gold plating, not actually following my clear TDD and SDD (nor properly using Playwright against my DoD, example mock ups, etc 2. What have you tried already? Matt Pocock’s system, BMAD, GSD(both old and new), Superpowers (I’m about to try pstack and ponytail to at least stop the gold plating) - I typically use Claude Code workflows with Opus/Fable plus Codex exec Sol and a Haiku wrapper for workflows / sometimes Codex directly sometimes with a voice agent orchestration - just started GrokBot but finding that is probably better for iteration than large spec / tickets / epics & stories? I tried one run with Atomic, mixed results - smaller things work great on that. 3. Where are you stuck? Getting the last 20% done and polished 4. What would a useful result look like? Finding a way to get that last 20% done rather than being the Human QA for literally everything! 5. What tools or systems are involved today? See above - maybe Cursor will be the answer? :) I don’t have that much experience with it yet - I have built hooks, etc for Claude, Codex, and now Grok Build. I use Matt Pocock’s skills, Ponytail, just started Pstack, (thanks Ray! Even Theo is talking about Lauren now!), a deny list a mile long (learned the hard way), GrokBot, codex etc.