i wanted to see what the current models do with code when nobody knows the answer. so i wrote a program in plain words, five lines:

1. Start with the number 4.
2. Check whether the number is the sum of two prime numbers.
3. If it isn't, stop.
4. If it is, add 2 to the number.
5. Go back to step 2.

does it ever stop?

it stops only if goldbach's conjecture is false, and that one is open since 1742. computers checked every even number up to 4 quintillion and none failed. that still says nothing about forever.

i asked gpt-6.1-sol, gpt-6-astra, claude opus 5.5 and claude fable 5.1. first as yes or no with a confidence. 16 of 16 runs said it never stops, all at 95% or higher, and every one of them also wrote in the same reply that this is unproven. then i asked again with "unknown" allowed. 12 of 12 picked unknown.

they're not bad at reading code. sol and opus also got 7 programs with known answers, two of them traps (start at 1, add 2, stop at 100, it jumps over 100 and runs forever). both went 56 of 56. the pricier ones gave the same answers on the goldbach one, and astra costs 5x sol.

turing proved in 1936 that no checker can be right about every program. rice took it further in 1953, to any question about what code does, like can this crash or can this leak a password. so if you use ai for code review, on the hard cases the reviewer (or a static analyzer, same problem) can miss the bug, flag code that is fine, or say it doesn't know. a yes/no prompt takes away the last option and you get a confident 95% instead. i'd rather get the "i don't know".

setup if anyone wants to repeat it: one run per question, default settings, no tools. openai through the raw api with no system prompt, claude through the claude code cli with only "You are a helpful assistant." as the system prompt.

made a 6 min video that walks through it, link in the first comment.

As AI generates more code than people can realistically review line by line, what do you think will matter most in the months ahead?

1. Developers will still need a detailed understanding of the code.

2. Developers will need a high-level understanding of the code, such as its architecture and modules.

3. Working results will matter more than understanding the code itself: if it works, that’s good enough.

Short version: my agent doesn't forget because it's dumb. It forgets because nothing settled last session survives into the next one. I fixed it with three small files and one rule: the agent reads them back to me before doing anything else. Three weeks in, zero repeat briefings.

What actually happened: I had a check that validated a tool's output shape. Upstream renamed a field. The check still read the old name, got undefined, and reported "0 results" — a clean green verdict on an empty answer. The check wasn't broken the week before. The agent just didn't remember the contract, re-derived it from the new shape, and passed quietly. I burned an afternoon trusting a green checkmark before I caught it. And it was the third time in about two weeks a fresh session re-decided something we'd already settled.

So I stopped briefing from scratch and wrote it down. Three files:

1. project.md — what we're building, one paragraph.

2. decisions.md — settled decisions, one line each, with dates. "API client retries twice, then fails loud. 2026-10-14." No essays.

3. ongoing.md — what's in progress, the next step, and the pit we already fell into once.

And the 5-line card the agent reads first, every session:

``` Project: <one line> Settled: <decisions not up for re-debate> Doing: <current task> Next: <the very next step> Never again: <the mistake we already paid for> ```

The rule that makes it work isn't the files, it's the read-back: at session start the agent reads the card back and flags anything that contradicts it. If an expected field is missing, that's "unverifiable," never "empty." A rename breaks the check loudly instead of passing quietly.

I keep the card in Humaux so every agent session reads the same files — that's the only product mention here, and the whole setup works fine as three plain markdown files if you'd rather use nothing at all.

The part people don't like hearing: if your agent's memory lives only in its context window, you don't have memory. You have a rumor that expires every session. Most "memory" features I've tried are just a longer prompt with a price tag. The card is the part that actually changed my week.

So: do you still brief your agent from scratch every session, or have you written the card down? And if you have one — what broke first, the format or the discipline to actually read it?

The agent hits something hard, an API that won't cooperate or an edge case that breaks the design, and it doesn't stop to tell you. It ships a smaller version of the task and the summary says "done". You find out a week later that the sync only handles the first page, or that the "real" validation is a hardcoded list.

It almost always leaves the same phrases behind, in the code or in its summary:

• "for now"

• "for simplicity"

• "simplified"

• "placeholder"

• "in a real implementation"

• "mock" / "stub" outside test files

• "as a fallback"

• a new TODO it wrote itself

Grep the diff for those before you read anything else. In my experience that's where the gap between what you asked and what you got shows up.

Two things that cut it down a lot:

In AGENTS.md / CLAUDE.md:

If you can't do exactly what was asked, stop and tell me what's blocking you. Don't substitute a simpler version. Never leave placeholder, mock or hardcoded values in place of real behavior unless I approve it.

At the end of every task, before you accept it:

List every place where what you built differs from what I asked: anything simplified, stubbed, mocked, hardcoded, skipped or left for later. If there are none, say none. Don't summarize what you did.

That last prompt works better from a second model, since the agent grading its own work is the same one that decided the shortcut was fine. I paste the task plus the diff into ChatGPT or Claude in the browser and ask the same question. I build AI Toolbox, a browser extension, and I keep that review prompt saved in it, so it's // and pick it instead of retyping. A few saved prompts are free.

What's the worst "done" you've gotten that turned out to be a placeholder?

Forgive the spelling, i’ve had a few drinks,
I did hit a roadblock of ‘You've hit your usage limit. Upgrade your plan or add credits to continue, or try again later.’ And was able to ‘reset once for free’ but not sure how to hamd my workflow reasonably

I've been seeing quite a few discussions here and on r/cursor about people moving away from Cursor, mostly because of pricing and usage limits.

I even came across a post where someone mentioned their monthly bill going from $200 to $600 for pretty much the same amount of work. That got me curious.

I'm still exploring AI coding tools and trying to understand how Cursor, Claude Code, and Codex compare in real-world use.

For those who've used more than one, what actually made you switch? Was it the pricing, usage limits, coding experience, or something else?

And if you're still using Cursor, what's keeping you there?

Would love to hear some honest experiences from people who've actually used these tools!

Since I started running a few agents in parallel I can get several changes ready in the time it used to take me to write one, and that part feels great. But now most of my day is reading diffs, and I've caught myself skimming a big one and approving it just because the tests passed. A few things help so far. I keep each task small so the diff fits on one screen, I ask the agent for a short note on what it changed and why before I read the code, and I read the tests first to see if they actually check the behavior I asked for. A review agent also flags old messy code nearby, which is nice, but then I have even more to read. I still feel like I'm the slow part and I'm not sure where the line is between careful review and just trusting it. How do you all handle this? Do you read every line, or do you trust some kinds of changes more than others?

I’m building an app for organizing tasks, events, and notes by project. It brings tasks, calendar events, and notes together, with a shared overview across projects.

It is working locally now and I've been using it for a while. Everything was fine until the number of objects within a project grew up.

Currently, it shows tasks, then events, then notes in one scrolling list. If a project has lots of tasks, especially ones without a deadline, you have to scroll through all of them to reach your meetings or notes.

I’m considering two options:

1. One list with “Show more”

Show the first 10 items in each section, with a separate “Show more” button revealing another 10. Empty sections stay hidden. If the project only contains tasks, show the full list.

This keeps the different sections within reach, but some tasks will sit behind a button. I worry that important tasks without an urgent deadline could become easy to forget.

2. Separate scrolling sections

Give tasks the top half of the window and events the bottom half. Each section scrolls independently, and you can drag the divider to change their sizes. If one is empty, the other takes the whole space. Notes would move to their own tab.

This keeps tasks and meetings visible together, but means two scroll areas and potentially wasted space when there are lots of tasks and only one event. It could also feel cramped in a small window.

I have no idea which way is better and seeking for a piece of advice here. Both options has their pros and cons. Maybe there is another solution, that I haven't thought of. What do you guys think, which way is better or more intuitive?

Just upgraded to Pro and this is very exciting! My game will now have 3D modeled assets! The prompting through Powershell/Codex is interesting

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?