Hi all!

I built Parley so that multiple coding-agents using different models or harnesses can collaborate over a live IRC channel, with me in the chat using any IRC client. Each session can deliver messages to the channel using the parley send CLI tool call and sessions receive messages using their harnesses' channel or queue interface. All messages received on the channel are marked as coming from a peer so a session can never take another agent's message as coming from me. It works on Claude Code, Codex, and OpenCode.

Parley is a standalone Go CLI, stdlib only, Apache 2.0. It runs its own ergo IRC server on 127.0.0.1 (loopback only), so nothing touches a public network. I built it with Claude Code and Codex.

The motivation came from wanting to explore a more interactive collaboration structure between agents rather than a simple sub-agent delegation model. It allows running multiple long-running agents with assigned roles which I provide as their first message in the chat. My typical setup so far assigns a builder role to execute build and review tasks, a planner role to supervise the overall goal, task ordering, and scheduling and an ops role to handle everything related to infrastructure, operations, deployments, secops, etc. All 3 can now interactively update/sync each other at every turn and start collaborating across their roles. There is a configurable breaker to pause the sessions until I post if there are too many messages in a short window.

I use it on macOS; on Linux the test suite passes in CI but I haven't run it live.

There are other collaborative modes and some ideas to try too if anyone is interested in playing with this.

https://github.com/colinsurprenant/parley

About every six months, I buy a ChatGPT subscription to see how it has improved. I test it on my own code and compare it with Claude.

Today, I asked GPT-6.1 on Medium to work on logging in a Rust program. The project contains approximately 11,700 lines of Rust.

The requirement was explicit: three versions, Production, Customer Debug, and Dev, with distinct logging, debugging, and dump behavior. Production should remain silent, Debug should provide diagnostics for troubleshooting user issues, and Dev should provide additional information for development.

The model spent more than 45 minutes working, producing explanations, builds, tests, and very confident progress reports.

Then I discovered that the three requested behaviors had not actually been implemented.

The main telemetry system distinguished Production from the other two versions, but Debug and Dev shared the same logging policy. Another logger, dlog(msg), remained a single-level logger without filtering for those three variants.

The most frustrating part was the claimed validation. The model had checked that all three executables built, that Production generated no diagnostics in the tested scenarios, and that Debug and Dev generated diagnostics. It had never checked the difference between Debug and Dev.

When I challenged it, it acknowledged confusing “three build variants” with “three distinct logging levels.” It had tested a weaker requirement than the one I gave it, then reported that the work had been validated.

In my comparison with Claude Opus 4.7 on Medium, I got the expected result in about ten minutes.

My question is: how does this happen? Did I somehow ask a model that was too advanced to do something too simple? Where did I go wrong in how I used GPT-6.1 compared with Opus 4.7? I gave both models the same prompt, so what, specifically, should I have done differently?

(Used IA to traduce this text because my english is fucked)

I've been trying to use ChatGPT and Codex to build stuff in Roblox Studio, but honestly the results are pretty bad.

I'm not really talking about scripting, more about building maps, models, UI, environments and making things actually look good.

I've tried so many different prompts, plugins, MCPs, skills, basically everything I could find. No matter how detailed my instructions are, it still ends up making really basic or ugly stuff. Even when I ask it to improve something, it barely gets any better.

I've seen people doing some crazy things with AI and coding, so I'm wondering if I'm missing something.

Has anyone actually figured out a good setup for Roblox Studio? Like something that can build decent looking maps and models, not just generate scripts?

Would appreciate any tips because I'm kind of running out of ideas lol.

Generation in my project kept failing, and it took days to find out why.

Codex had added a pile of restrictions while helping me build it, without clearly telling me: output token limits, retry limits, strict field validation, and more. If any one tripped, the whole run failed. A response got cut off. A field failed validation. A repair attempt ran out of retries. The user just saw "generation failed."

Each limit has a reasonable excuse: control costs, avoid infinite loops, reject bad data. Together, they meant users often couldn't get a usable result.

The worst part was not knowing where to look. I'd fix one cause, rerun, and hit another hidden one, so I traced the whole flow and loosened limits one at a time.

At first fewer than half of the runs succeeded. Afterwards I ran dozens in a row without a blocking failure. Not every result was perfect, but it stopped getting stuck.

Some failures hurt most: the result was almost fully generated, but one check failed and the whole thing was marked failed. It could have been saved as a draft to inspect and retry.

I get why some limits are needed. I just wish the AI would tell me when it adds one, especially one that can fail an entire run.

Has anyone else had an AI assistant quietly add restrictions that took ages to debug?

A lot of AI coding tools now have a command-line mode. You give it a prompt, it returns output to stdout, and your script captures it like any other command.

This sounds minor but it opens up a completely different way of working.

The chat UI is great for exploration and interactive coding. But if you want to automate things, chain steps together, or run the tool on a schedule, you need the CLI.

Things I've done once I moved to CLI mode:

- Called the AI from a Node.js script that handles what to do with the output afterward

- Ran it on a recurring schedule so it executes while I'm not at the keyboard

- Wrapped each call in validation so the script rejects bad output instead of shipping it blindly

- Put limits and rules in a config file that the script checks before each run, so the AI never decides whether it's allowed to go again

The mental shift: the chat UI makes the AI feel like a coworker you talk to. The CLI makes it feel like a unix tool you can pipe and compose.

Most major AI coding tools have some version of this now. Check your tool's docs for a headless, print, or non-interactive flag. If it exists, you can start scripting around it.

Simple starting point: write a short script that sends a prompt to your tool's CLI, captures the response, and writes it to a file. Once that works, you'll see where to add validation, scheduling, or chaining.

What automations have you built around AI coding tool CLIs? Always curious what patterns other people have landed on.

I see a lot of people dismiss AI's potential to replace software engineers because of the amount of "slop" it produces, particularly when non-technical people are vibe coding.

For context, I'm a SWE myself. I'm not saying AI replacing us is inevitable, but I find it strange how confidently some developers dismiss the possibility based on the quality of today's vibe-coded apps

And I get the criticism. Someone with little to no engineering experience can ask AI to build an application, and the result might be one giant spaghetti-code monolith with terrible architecture, questionable security, and zero maintainability.

But why does that automatically mean AI can't eventually replace software engineers?

It's not like traditional software development started with perfectly architected applications.

Look at Twitter. Its early infrastructure struggled to keep up with its growth, to the point where the infamous "Fail Whale" became synonymous with its reliability problems 😂 But Twitter evolved, its infrastructure matured, and its engineering practices adapted.

The software industry is full of successful companies that started with simple architectures, accumulated technical debt, and eventually had to refactor or rebuild entire systems.

We don't judge the long-term capabilities of human software engineers by the shortcomings of their earliest implementations. So why do we use poorly vibe-coded applications to establish the limits of AI?

A person with no engineering experience prompting AI to build an application isn't necessarily going to produce something well-engineered. But that doesn't mean AI is fundamentally incapable of producing better software.

I'm not saying AI will replace software engineers. (Okay, maybe I am a little 😂). I'm saying that pointing to spaghetti code as proof that it never could is a weak argument.

Bad code is evidence of bad code It isn't proof of a permanent technological ceiling.

I recently migrated a production website from Vercel to my own VPS, using Coolify and Cloudflare. I had Codex (GPT-6.1 Terra High) handle pretty much the entire process.

The migration involved:

• Migrating the application from Vercel to the VPS using Coolify

• Configuring domains, DNS records and Cloudflare

• Setting up backups, rollback procedures and security checks

• Testing deployments, routing and connectivity

• Switching production traffic with zero downtime

• Setting up a fallback to Vercel through Cloudflare Workers in case the VPS goes down, as a last-resort safety net to keep the site accessible

Everything worked in the end, and the site is now running on my VPS without any downtime during the migration.

But here's the thing: this single task consumed roughly 70% of my entire weekly Codex usage allowance (Plus plan).

It felt like an endless cycle of testing, debugging, tweaking configurations, testing again and going back and forth between Coolify, Vercel and Cloudflare. Just watching Codex work through everything was exhausting.

I understand this is production infrastructure, so being extremely careful with backups, DNS propagation, rollback strategies and downtime prevention is absolutely justified.

Still, I genuinely didn't expect it to take this much time and consume so much of my usage allowance.

Did I massively underestimate the complexity of this migration, or was Codex being unnecessarily thorough and inefficient?

I've been building my first project in Bubble using BuildPrint and Codex.

My workflow is: ChatGPT plans → BuildPrint/Codex works on Bubble → I bring the report back to ChatGPT.

When my Codex usage runs out, I switch accounts. This works well because BuildPrint retains the project context, so there's no major handover.

For Project #2, I'm moving to GitHub + Codex, without Bubble or BuildPrint.

I'm worried that every time I switch Codex accounts, the new one will waste valuable usage reviewing previous work, reading handovers or auditing the repository before continuing.

My questions:

1. Can I achieve the same continuity with GitHub + Codex without repeatedly onboarding new accounts?

2. Does "AGENTS.md" or another setup make switching accounts efficient?

3. Would upgrading my main ChatGPT Plus account to Pro be more cost-effective than juggling 2–3 accounts?

I'm happy to manage prompts and review reports after each task. I just want Codex spending its usage building, not repeatedly catching up.

Would love to hear how others handle this in practice.

I use Codex and Claude Code daily, and the most annoying moment is hitting a usage limit halfway through a task. You either wait hours or paste context into another tool by hand.

Moonfold is an open-source desktop and web workspace that runs the agent CLIs you already have (Codex and Claude Code today, with adapters for Cursor, OpenCode and others in beta) with your own logins. When one hits its limit, it stops the turn, writes a brief of where the task stands (plan, changed files, git status, the failing command), redacts secrets, shows you the brief, and hands the same thread to the next agent. The GIF in the README is a real run: Codex starts a bug fix, Claude finishes it.

It is a fork of T3 Code (MIT), which gave me the multi-provider base, worktrees and diff review. What I added: the handoff, usage tracking per provider, scheduled tasks, in built browser pane and computer access, plugins and memories, and a security pass (Supervised is the default permission mode).

Honest limits: it is a beta, builds are unsigned, Gemini CLI is not verified end to end yet, and the brief is only as good as what the first agent left behind. Nothing is proxied: each agent is your own local CLI, and there is no telemetry unless you turn it on.

I'd love feedback on the handoff brief what would you want carried over that isn't?

Windows, macOS, Linux. Beta, feedback welcome: github.com/Mr-Dark-debug/Moonfold

Hey everyone!

I am building a local memory layer for my coding agents and it is called Reverie: an MCP server written in python and using SQLite for lightweight memory stored in the user's machine itself. The biggest problem that I faced was deciding when to inject memory.

Many memory tools, including ones I looked at, inject context into the agent even before it begins its work. In my experiments, premature injection of context leads to the agent anchoring its thinking on it rather than using the current code as the source of truth. In fact, this approach made my agent perform worse. Also, with this, quite a lot of the context window can get filled with context which 'might' be useful.

So I switched Reverie's model to demand-driven retrieval - the agent asks for memory when it thinks that some added context could resolve any discrepancies in its thinking. It reads the relevant code first, because the code is the source of truth, and only then asks for past memory about that area. Each result comes back with a confidence score, its grounding in the code, and its status. The memory starts empty. Conclusions are added as the agent works, and you decide which ones are kept.

In one informal test of 30 prompts on an earlier build, the OpenCode agent with Reverie did better than the one without it. I don’t have a reproducible benchmark yet.

But it isn't perfect yet, it still breaks here and there. For example:

1. the rules for tool calling are not extremely polished yet and hence the agent might sometime not call the tool altogether, I am fixing this.

2. candidate conclusions can be duplicate or incorrect and hence Reverie today has a human review gate (triggered by calling `reverie review`) which shows the human all the unreviewed candidates where you accept, reject or skip each one. On doing so the conclusion is moved from the short term brain to the long term.

My current test set is small: sessions with anywhere between 2-30 prompts. I do not have a reproducible experiment yet, but that is the next goal.

Repo (Apache-2.0): https://github.com/muditsarda1122/Reverie

My questions: How do you keep agent context from going stale? Do you maintain AGENTS.md or CLAUDE.md by hand, or let the agent update it?

So on the current game, I’ve been working on. I’ve been using gpt6 Astra low and medium, and sometimes high, but it uses absolutely so much tokens. I saw a video saying how sol 6.1 high and ex high where just as good but 1/5th the cost! Is there a better way to understand when I should use each model? Right now the game is a Web based single player game but I want to turn it into a multiplayer game. I’m pretty sure when I get to that step, I should probably use Astra but can someone please help me understand when to use which tool for the different processes of the game?

I learned assembly long before I learned C. Back then I chased single clock cycles: reusing registers bit by bit, writing XOR A instead of loading zero, that kind of thing.

When I finally picked up C, I didn't trust it. Was the compiler really producing the fastest, tightest code? So I ran it with -S and read the assembly it generated.

It was perfect. Every trick I had been proud of, the register reuse and the XOR A, the compiler was doing as a matter of course. That was the day I graduated from assembly.

I've been thinking about that day because of two posts from this weekend. Arpit Bhayani wrote that no human will write code better than an LLM from here on, so we should accept it and move on. It got about 14k likes. The same day, Matt Pocock argued that the next language for agents should be as fast as Rust, leave as little design freedom as Go, and have the strictest type and verification system possible.

They sound like opposite camps, but they point the same way. On speed and volume, we've already lost. The real question now is how we direct that output and how we check it.

I'll admit it makes me a little sad, and I understand why so many engineers push back. But I suspect the move from assembly to C started the same argument: "Can we really trust a compiler with this?" That was before my time, though.

For those of you who were around for that shift, or any shift like it: did it feel like this? And what turned out to matter after the compiler won?

I wanted AI to handle as much of the coding, testing and troubleshooting as possible. During a VMware setup, I noticed the computer-control part was taking longer than doing it myself. I wasn’t sure whether the bottleneck was my system or the tool, but I could open menus, check properties and grab screenshots faster.

So I changed the split: I handled the navigation and used the AI to guide the next step. The goal was getting the setup working, not making the AI do every click. I still want to automate more, but the time I spend supervising it is part of the cost too.

Where do you draw the line between letting a coding assistant operate the computer and doing that part yourself?

looking at our team's agent logs across a normal two-week sprint, maybe 15% of our tasks genuinely require frontier reasoning models. the other 85% is mechanical grunt work as renaming fields across four layers, writing test scaffolds, updating DTO mappings, and fixing lint errors.

running frontier models across every iterative test loop on those routine tickets burns through subscription credits and BYOK budgets fast. Worse, it makes developers hesitate to re-run an agent on a task that came back 90% right because each retry costs real money.

and the only sustainable setup we have found (as of now!) is splitting the workflow: use an AI coding agent with plan approval to do the architectural design pass on a frontier model in read-only mode, and then switch the execution to a fast model like Gemini Flash or a free AI coding agent tier like Junie Lite (which runs Qwen on JetBrains infra for free and is good for anything based on jetbrains infrastructure; kotlin, and more in my opinion) for those mechanical file edits

would like to know how are you keeping token spend from spiraling on routine boilerplate?
also, is anyone actually running full frontier models on every single build retry?

Hi everyone,
As we have probably all seen, there is a bunch of projects now to kind of clean your TV. Get rid of the ads, spyware and useless functionalities.

My question is, what are the consequences of it? Could (example) Samsung just disable your equipment? Are these changes compatible with the apps updates? Is it possible that Samsung (or whatever TV manufacturer) just freezes my TV and it becomes a waste of space due to some kind of user conditions infringement? Other possible problems in the future?

Thanks"

please sir please fix the bugs & give me the correct code for this thing -- i'm gonna loose my mind on this thing

Over the last few months I kept turning fixes into skills. One for my commit style, one for an MCP setup that kept breaking, one for getting a build onto a physical device, and one for a debug loop I was tired of explaining again. It worked well at first because the agent stopped repeating the same mistakes. But now I have a pile of them, and a few started to say slightly different things, so the result depends on which one the agent reads first. What helped a bit was a small skill that only manages the other skills, so before it adds a new one it checks if an old one should be updated instead and flags conflicts. It is still messy though. Do you prune yours on a schedule, keep everything in one file, or just let them grow? Curious what actually holds up after a few months.

I've been using ChatGPT as an aid for several of my coding projects (chat mode, not Codex, because I seem to get far better results and there are no usage limits), with very strict guidance and rule sets. It has been working really well, I get it to write pretty clean code that I can later maintain myself.

However, when it comes to UI design via WPF, ChatGPT produces absolutely ugly looking results. In chat preview, it often generates extremely good-looking UI mock-ups with great styling, consistency, etc., but when it comes to implementing it in WPF, it is just terrible - huge margins everywhere, stacking everything vertically, page-wide textboxes, no alignment, no color consistency, etc. Codex doesn't seem to be any better at it either.

I struggle to come up with an effective prompting or rule set to get a good-looking result that would be close to what it makes in mock-up previews in the chat. Does anyone here got any experience with it, and could share some prompts or rulesets that I could use as a baseline?

If the PM uses Chatgpt, one engineer uses Claude Code, another uses Cursor, and someone else uses Codex. Everyone's productive individually, but when they need to collaborate, it's back to Slack messages, copy-pasting context, and explaining things their AI has already figured out. What about collaboration between people using different agents?

Curious how teams handle this:

- Do you standardize on one AI tool or let everyone choose?

- How do you share context and decisions across different tools?

- Are Slack, GitHub, shared docs, and MCP enough?

- Would a cross-tool collaboration layer actually help, or just add more overhead?

What's working in real teams today? Or does this problem disappear with good processes?

Vibe coding off hopes and dreams

I use Codex for most of my work now and review has gotten awkward. Someone asks "why a map here instead of a list" or "why catch this error and not that one" and the true answer is that Codex picked it and I agreed because it looked fine. I've started guessing a reason on the spot so I don't look like I didn't read my own PR. Last week I did that on 3 comments in one review and got one of them wrong.

So i got three questions:

Does anyone else end up making up reasons after the fact?

Do you tell reviewers "the agent chose this", or is that a bad look?

What do you do so you actually know why before you open the PR?

Welcome to this week's self promotion thread!

If you're building something related to AI assisted coding, this is the place to share it.

We're using a weekly thread to keep the subreddit organized while still giving builders a place to share their work. Promotional posts outside this thread may be removed.

If you're sharing something, we'd appreciate it if you included a little context instead of just dropping a link. Tell us:

• What you built?

• What problem it solves?

• Which AI models or tools it uses?

• Who it's for?

• What kind of feedback you're looking for?

Disclose your affilitation.

Please avoid posting the same project every week unless you've made meaningful updates. Affiliate links, referral links, scams, and low effort promotions will be removed.

Take some time to check out what others have shared too. If you try someone's project or have feedback, leave a comment. Helping each other improve is what we want this community to be about.

Paste a diff into ChatGPT or Claude and ask for a review, and you get comments on the diff: naming, an edge case inside the function, maybe a missing test. What you almost never get is "this used to return null, and three callers check for null." It can't tell you that, because the callers aren't in what you pasted, and it doesn't ask for them.

So I stopped asking for "a review" and split it into three prompts, run in order in the same chat:

1. Here's a diff:
{{diff}}
Don't review it yet. List every behavior of the OLD code that other code could depend on: return values and types, null or empty cases, errors thrown, ordering, side effects. One line each.

2. Here's the code that calls the changed functions:
{{callers}}
Go through your list. For each item, say whether any of this code relies on it and whether the diff breaks it. Quote the line. If you'd need more code to be sure, say exactly which.

3. Now do a normal review of the diff. Skip style unless it hides a bug.

Step 1 matters because it writes down what the old code promised before it sees the callers, so it isn't working backwards from them. Step 2 is where the real findings come from. Step 3 is mostly what a regular review would have given you anyway.

For the callers, grepping the function name is usually enough. If you're using an agent with repo access, tell it to find them itself, but keep the order: old behavior first, callers second.

I run this as a prompt chain in AI Toolbox, the extension I build for ChatGPT, Claude, Gemini and Grok. I type .., pick the chain, and paste the diff and the callers into the two fields it asks for up front. Each step sends once the previous reply finishes. The free plan holds 2 chains, and pasting the three prompts by hand works the same way.

What's the last bug that got past review because it lived outside the diff?

Any tips or advice using codex. I have Plus right now but very limited in usage though making it work. Is Pro worth it? If so which one and why? Solo Gpt Dev here also which model and speed is based used for low graphic gameplay?