First things first get opencode installed https://opencode.ai/ and connected to your provider (works with almost everything except Claude Max).
Then the workflow is like this for each repo (both greenfield and existing):
1. Create an opencode.json in the repo root. opencode.json is the harness config. It tells the system what provider/model endpoint to use, which instruction files to load, what the default agent is, what specialist agents exist, and which slash commands route to which agent/workflow. For now, it can be very simple and barebones.
2. If you have any existing CLAUDE.MD or AGENTS.MD files you like to use, you can point them in opencode.json as "instructions" key. So here's a sample config (or look at https://opencode.ai/docs/config/)
{
"$schema": "https://opencode.ai/config.json",
"instructions": ["AGENTS.md"],
"default_agent": "build",
"agent": {
"coordinator": {
"description": "Lead coordinator",
"prompt": "This will be the prompt for your coordinator agent",
"agents": [
"componentA_build",
"componentA_meta"
]
},
..."
3 [the most crucial step]. Create a plan of how the repo is structured to feed back into the harness so it can generate its own tailored config.
Of course, this is where your own critical thinking comes in. You're going to be prompting the default agent to start extending this opencode.json to fit your project. I found that most models are relatively poor at sussing out the "why" of an existing codebase - they are much much more focused on the how and what.
So much like how companies ship their org chart, with gen AI code you ship your architecture. If you don't have a good mental model of how the game should work (not that it HAS to be working that way now, but how it should be), then you won't go anywhere. If you can provide the "why", that is the connective tissue that really makes the difference.
For instance, lets say you are working on a railroad simulation game with a modular architecture - there's one central "GameController" which references submodules like "CityController", "TrainController" and so on. You'd then want to create agents that specialize in things like cities, trains, railroad, building, etc with a high level "coordinator" agent that has access to every subagent (as defined in the "agents" key). And then you get to the fun part of making higher-order agents - so an agent that specializes in game balance that has CityAgent, TrainAgent, GameAgent etc as sub agents, "RouteAgent" that has RailroadAgent, TrainAgent etc that specializes in efficient routing calculations and so on.
I found that in this step it helps just to braindump into a scratch pad and just write out as much as you can at a high level how it all operates and the architecture and the agents you want. Having a defined OUTPUT is the most important part of the agentic process and prompting. Key things I have in this braindump:
a. Architecture overview, both "actual" and "idealized" versions (what do we want the end game to look like e.g. a full-fledged train sim with stock market and city building - even if currently its just an isometric map with some buttons on it).
b. Core components of the system
c. Key file locations, any workflows like processing images, audio etc for game
d. Any design decisions and whatnot you made that aren't captured in code or documented (e.g. "I'm basing the economy off of XY Game")
One thing that's VERY helpful at this phase is having the default agents ("Build" and "Plan" with OpenCode) go through and document all the code and as much as it can into a docs folder if you don't have that already.
4. Take that braindump and feed it back in OpenCode and tell it to modify its opencode.json to have agents to handle all the components and architecture. Tell it to parallelize and delegate as much as possible.
5. It'll output a new opencode.json. Restart opencode and go wild.
As you work with the harness, you'll get the nuances of how the agents are interacting and what needs some tweaking but the key here is to always keep the feedback loop going. Tell the agents to always update docs after committing code and to always read the docs before doing anything etc etc. This is key to making sure the agents don't go off-rails.
Eventually you'll see the meta-patterns you like and create scripts to e.g. autogenerate this kind of harness for any repo you encounter. I don't have one "source of truth" opencode.json but rather a base template and then a python script that does all of the above automagically for my workflows.
The key insight here, I think, is like learning Lisp. The harness IS code, agents ARE Code - they can be modified as needed dynamically and adapted. They are first-class citizens and can be composited like functions or chained together like graphs. The map is the territory. Once I realized that I could prompt the harness to modify itself and do all the things to itself that it does to the codebase, things really took off for me.
Anecdata disclaimer: This workflow might not fit everyone's mental coding model. Adapt as needed. I use literally dozens of these kind of harness configs every day at work, including meta-harnesses with code review of harnesses and EvalOps. Been doing so for about six months now. I'll also note we are very serious about performance and feature degradation but with this approach we've had less rollbacks and regression than in the previous five years.
OpenCode harness is so good I'm surprised one of the big players hasn't bought them outright. Essentially their harness:
* Removes all the system prompt cruft and bullshit that CC pumps into the prompt and pollutes context and shit like "adaptive thinking"
* Is extremely good at keeping the model aligned with AGENTS.MD and opencode.json and using all the features available there (parallel agents, sub-sub agents, etc)
For example, I'm working on a repo with 5 distinct components and I have a specialized agent for each component. CLAUDE.MD is just a markdown file where I say "Hey Claude always use X agent for X component. X agent has this prompt blah blah" and then pray Claude remembers to use it. opencode.json is a structured file used by the harness and it has ALWAYS coerced the model to use it, including being able for the agents to delegate subagents in parallel etc.
This makes a massive difference. So if I have a feature that touches multiple components, OpenCode rips through it with the specialized subagents while Claude sits their spinning its wheels and occasionally remembering theres a specialized agent and then maybe once in a blue moon it will do it in parallel.
With CC I feel like I need to do all these invocations and coercions. OpenCode, once you've got your opencode.json and agents defined, just works.
Claude the model is still insanely great IF (and perhaps, ONLY IF) you are willing to fork over the money for the API and use a harness like OpenCode.
Claude Code itself is complete trash. They had a massive headstart and now are routinely lapped by open source harnesses and then they STILL double down on not allowing e.g. OpenCode usage with the Max plan. Meanwhile, OpenAI lets you use whatever harness you want and its a beast. I recently did some testing and OpenAI's Pro plan on an opencode harness (GPT 5.5 XHigh) with parallel agent delegation absolutely smokes Claude Code 4.7 Max. These days Claude Code can barely even remember its CLAUDE.MD instructions. I'd say Opus 4.7 Max API is slightly better than GPT 5.5 XHigh, but not nearly enough that the API token price is at all justified.
Claude, I think is still better for business things like document generation, design, etc. especially via claude.ai interface (GDrive integrations and things like that are very useful). But for code generation and dev workflows, Claude Code is dropping the ball so hard its starting to look like a generational fumble.
I recall having a few interviews for MLOps jobs in 2022/2023 that had a sort of AI safety component to the interview. Not necessarily a deep philosophical debate but rather a conversation about AI limits, user discovery and usability, that sort of thing although I did touch upon alignment, guardrails, responsible computing type stuff.
Recently I did a few interviews in the same space and this wasn't even a consideration - I think the genie has left the bottle. Signaling about AI safety and alignment is being shed in favor of technical execution and speed, probably because we're starting to see the plateau forming with regards to machine intelligence and how far off AGI/ASI truly is.
Does anyone have any additional context on the throughput numbers? It says 20k photons per second at 99% fidelity and 500k at 90%, but what is the actual bandwidth needed for reasonable usage / computation?
I run a gamedev studio and make a lot of titles in Godot. ChatGPT is an absolute beast at GD Script 3.5.3 and also parsing scene files - I assume because Godot is entirely open source with lots of docs online. It will occasionally hallucinate built-in functions but that's easily caught and rectified. Saved me a ton of time when I had to write custom pathfinding scripts. It's also given us more velocity with features where we can kind of just toss off fun "juice" ideas to it (like minigames or easter egg type content) and get back a workable script in minutes that would've been like a weekend stretch goal.
A pet project I have in my head is using another LLM with a huge context window and being able to dump in all the scene and script files so the AI has insight into the entirety of the game and how the nodes interact rather than just the isolated scripts I send. Not sure if this is feasible locally with the same level of accuracy as Claude or ChatGPT
Trying to keep it "realistic" in the sense of how the structures are set up (bank reporting regulations, offshore companies, shell companies etc) but I'm optimizing for fun. It's an isometric Transport Tycoon-styled game but instead of building physical infrastructure you create financial connections between nodes like drug op -> cash business -> bank -> offshore company -> real estate investment.
Would be very cool to be able to highlight sections or even an entire file and then have a right-click option to "Refactor Code" which, rather than being additive, would clean up and condense the code according to the idioms of the language.
Relatively light moderation, anonymity discourages "power users" and annoying personalities clogging up threads, and the unfiltered and transitory nature of discussion. Feels like a last vestige of the old pre-social media internet. Mostly they're just fun
First things first get opencode installed https://opencode.ai/ and connected to your provider (works with almost everything except Claude Max).
Then the workflow is like this for each repo (both greenfield and existing):
1. Create an opencode.json in the repo root. opencode.json is the harness config. It tells the system what provider/model endpoint to use, which instruction files to load, what the default agent is, what specialist agents exist, and which slash commands route to which agent/workflow. For now, it can be very simple and barebones.
2. If you have any existing CLAUDE.MD or AGENTS.MD files you like to use, you can point them in opencode.json as "instructions" key. So here's a sample config (or look at https://opencode.ai/docs/config/)
..."
3 [the most crucial step]. Create a plan of how the repo is structured to feed back into the harness so it can generate its own tailored config.
Of course, this is where your own critical thinking comes in. You're going to be prompting the default agent to start extending this opencode.json to fit your project. I found that most models are relatively poor at sussing out the "why" of an existing codebase - they are much much more focused on the how and what.
So much like how companies ship their org chart, with gen AI code you ship your architecture. If you don't have a good mental model of how the game should work (not that it HAS to be working that way now, but how it should be), then you won't go anywhere. If you can provide the "why", that is the connective tissue that really makes the difference.
For instance, lets say you are working on a railroad simulation game with a modular architecture - there's one central "GameController" which references submodules like "CityController", "TrainController" and so on. You'd then want to create agents that specialize in things like cities, trains, railroad, building, etc with a high level "coordinator" agent that has access to every subagent (as defined in the "agents" key). And then you get to the fun part of making higher-order agents - so an agent that specializes in game balance that has CityAgent, TrainAgent, GameAgent etc as sub agents, "RouteAgent" that has RailroadAgent, TrainAgent etc that specializes in efficient routing calculations and so on.
I found that in this step it helps just to braindump into a scratch pad and just write out as much as you can at a high level how it all operates and the architecture and the agents you want. Having a defined OUTPUT is the most important part of the agentic process and prompting. Key things I have in this braindump:
a. Architecture overview, both "actual" and "idealized" versions (what do we want the end game to look like e.g. a full-fledged train sim with stock market and city building - even if currently its just an isometric map with some buttons on it).
b. Core components of the system
c. Key file locations, any workflows like processing images, audio etc for game
d. Any design decisions and whatnot you made that aren't captured in code or documented (e.g. "I'm basing the economy off of XY Game")
One thing that's VERY helpful at this phase is having the default agents ("Build" and "Plan" with OpenCode) go through and document all the code and as much as it can into a docs folder if you don't have that already.
4. Take that braindump and feed it back in OpenCode and tell it to modify its opencode.json to have agents to handle all the components and architecture. Tell it to parallelize and delegate as much as possible.
5. It'll output a new opencode.json. Restart opencode and go wild.
As you work with the harness, you'll get the nuances of how the agents are interacting and what needs some tweaking but the key here is to always keep the feedback loop going. Tell the agents to always update docs after committing code and to always read the docs before doing anything etc etc. This is key to making sure the agents don't go off-rails.
Eventually you'll see the meta-patterns you like and create scripts to e.g. autogenerate this kind of harness for any repo you encounter. I don't have one "source of truth" opencode.json but rather a base template and then a python script that does all of the above automagically for my workflows.
The key insight here, I think, is like learning Lisp. The harness IS code, agents ARE Code - they can be modified as needed dynamically and adapted. They are first-class citizens and can be composited like functions or chained together like graphs. The map is the territory. Once I realized that I could prompt the harness to modify itself and do all the things to itself that it does to the codebase, things really took off for me.
Anecdata disclaimer: This workflow might not fit everyone's mental coding model. Adapt as needed. I use literally dozens of these kind of harness configs every day at work, including meta-harnesses with code review of harnesses and EvalOps. Been doing so for about six months now. I'll also note we are very serious about performance and feature degradation but with this approach we've had less rollbacks and regression than in the previous five years.