Activity
Mon
Wed
Fri
Sun
Sep
Oct
Nov
Dec
Jan
Feb
Mar
Apr
May
Jun
Jul
Aug
What is this?
Less
More
Start My AI

297 members • Free

4 contributions to Start My AI
AI Builder Room — How should I have structured Battle Harnesses from the beginning?
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.
1 like • 1d
@Maria Martins Awesome! If anything else we can help with let us know and if you run into any issues/have feedback we can iterate on as you're using Atomic
0 likes • 10h
@Tanya D of course! Excited to hear more as you try it.
Fellow canadians
Hello any one in toronto Canada?
0 likes • 3d
@Ray Fernando @Andres Perez yes we're seeing a rush of excitement for verification and scaling much of research across various topics through the runtime. We are grateful for their research, and are also iterating on some of their interesting learnings in the next, next release of Atomic (v0.9.15) so you can get the benefit of their learnings + a lot more goodness at production scale.
0 likes • 3d
I am not in Toronto but we have cousins that are and love the city
This is what I love the most about Atomic
Sure it can do very complicated things, but this part of having models reviewing other models is golden lol for research, unbeatable
This is what I love the most about Atomic
1 like • 5d
@Maria Martins this is awesome - cool use case I hadn't seen this one before.
okkk has anyone tested Buzz? 👀
I'm having so much fun with it! I know it's an early project but to have a council to discuss plans, either execution or brainstorming things, it's amazing! Great great results!
0 likes • 11d
@Kalen Howell nice! How's it going so far with Codex + Atomic?
1 like • 9d
Hey @Maria Martins, those specific authentication errors are not generated by Atomic. Atomic does not use providerAccess, does not have an --allow-api-provider option, and does not produce the “configured with non-subscription authentication” message. It's most likely another tool. I do recommend using Atomic as a first party when possible. We're working on an ACP server to make it more seamless to integrate with other interfaces like T3 code. Atomic by itself does automatically fallback to other models if they are configured and the error is recoverable. Thanks for flagging the bun docs bug! npm-installed Atomic runs under Node, so the documented Bun.spawnSync examples fail even if Bun is installed. We'll fix this. A workarond if you run into this for now you can prompt atomic: "Fix this workflow by replacing all Bun.* APIs with Node-compatible APIs such as node:child_process, then rerun it." You can steer or resume existing runs with this instruction too.
1-4 of 4
Norin Lavaee
2
15 points to level up
@norin-lavaee-2231
Building Atomic, agent infrastructure, search, and other work I’m excited about. Open source @ https://github.com/bastani-inc/atomic

Active 10h ago
Joined Aug 5, 2026
Powered by