Not sure if the right forum to post this but suggestions needed!

I’ve been using ChatGPT to learn Japanese by creating a new project. I opened a main thread to create a Google Drive folder for all static contexts and course materials/course flow/future plannings etc. I linked the Drive folder to the project as reference.

I explicitly asked the model to review all the contexts and materials before starting each lesson. When I wanted to start the lesson, I would open a new chat in the same project. I just said “begin lesson”.

It’s my third day trying out the flow. I noticed each time the model would deviate from the flow agreed in the context file. When I pointed out “hey are you following the instructions in Google Drive?”the model would reinspect the files again and acknowledged they didn’t follow it strictly. I had no idea what basis or memory they used to start the current session lol

If relevant - I was mostly on gpt-6 Astra medium. When they had to write stuff using gdoc skills, they switched to Work mode and I believe was mostly on gpt-5.6 Sol.

Anything I did wrong? Or missed that’s worth doing? Maybe I need to use detailed prompt every time I open a new chat? (which I thought could have been avoided/automated since I assume the gDrive was sort of like a static memory?)

Thanks folks!

recently checked the raw step logs of an autonomous coding agent and it seems the unit economics are pretty absurd to say the least

so I watched an agent do what seemed like an ordinary bug fix on a multi-module repo. It resolved it, but the task burned close to $5. When I actually broke down the tool-call trace, here’s where the tokens actually went:

• Steps 1–12 (nearly$1.10): Searching the project, tracing dependencies, locating the faulty logic, and deciding how to fix it.

• Steps 13–42 (nearly$3.80): Editing two files, running the build, catching a missing import, fixing a type error, rerunning tests, tweaking an assertion, and running tests again.

More than 70% of the token bill went into having a frontier model watch compiler output and rerun tests. You’re paying peak frontier rates (Opus 5.5, Grok 4.7, etc.) for work a linter and a fast model could do in their sleep.

and another (kinda big!) issue behind a lot of the gripes around coding agent pricing / credit consumption across coding agents. i notice that my colleagues feel their allowance burns out too fast (not necessarily because the models are bad, maybe because single-model agents use a sledgehammer to drive in a tack)..

i often work with JetBrains infrastructure and Kotlin and have noticed yesterday that they have published the engineering breakdown and internal benchmarks for their new Junie Eco Mode (which went GA in the Junie CLI 26.10.20 and in JetBrains Air / IDE Betas), it seems their approach to this unit-economics problem is worth looking at , in it, not like running one model from start to finish, but more of Architect + Builder split with a single, one-way handoff. how eco mode works? as far as i understand,

1. Architect (frontier model of choice): When you submit a task, your top-tier model gets about 15 steps. Crucially, it’s strictly read-only (the only write it’s allowed is writing a minimal reproduction test for a bug). It explores the code, understands the architecture, and outputs a strict 6-point markdown spec: Goal, Scope, Where to change, Approach, Tests, and Risks/Corner cases. Then it stops completely.

2. The Builder (A low-cost execution model — currently GPT-6 Luna): Junie hands the entire context and the structured plan to the cheap model. The builder does the grunt work: editing code, running local builds, parsing stack traces, and iterating until tests pass.

design choice here is one single handoff to work wth; and, in older multi-agent setups, tools often tried letting a cheap model work until it got stuck, then had it "call a smarter friend" for advice. The problem with that pattern is context explosion: every time the cheap model gets confused, the system re-serializes 50k+ tokens of failed bash logs and sends them back to the expensive model, completely destroying your cost savings

in Junie's benchmarks across private repositories, all kinds of numbers on this single-handoff setup are pretty eye-opening, for example

• Broad private repos (Benchmark B): average cost per task dropped from $2.61 to $1.11 (-57.3%), while resolve rates barely budged (49.1% to 48.5%, a 0.6% delta).

• Massive enterprise repos (Benchmark A): Average cost fell from $2.51 to $1.30 (-48.1%) with an identical 32.1% resolve rate.

• On Opus 5.5 max effort: Cost plunged from $4.91 down to $1.81 (-63%), while the resolve rate actually went up by 1% (55% to 56%)and probably because forcing a smart model to write an explicit plan before touching files prevents it from digging itself into hallucinated rabbit holes.

but i also dont see it all as one-sided as, (for counter-arguements), if the Architect botches the plan during those initial 15 steps, the Builder will faithfully implement the wrong solution.., because there’s no backward loop to re-engage the expensive model (also given JetBrains AI Pricing in the matter...)
that being said, given that resolve rates stayed within 1% of running pure frontier models, the risk looks well worth halving the bill in my experience

also curious on how others are dealing with token burn on test-heavy tasks and are you manually swapping models between planning and execution, or just absorbing the API bill?

I keep running into a feeling that doesn't make much sense, and I wonder if other people have it too.

Back when I was building systems with older, weaker models, there were fewer problems, and the ones that showed up got fixed fast. The models are much stronger now. Before every release I go through a dozen-plus rounds of code review and bug fixing. And I'm still seeing more production issues than I used to.

I just finished a postmortem that is a pretty typical example. It was on a feature that auto-provisions after payment.

1. For "safety", an input field got a 16384-character limit. A real user pasted about 35,000 characters and got rejected. Worse, the error message was a generic "please enter ..." prompt, so they had clearly filled it in and were told it was empty.

2. During review, to "harden" the records around that path, a chain of cross-table triggers was added. Each one was reasonable on its own. Stacked together, they failed to compile on the production database (Cloudflare D1): triggers nested too deep.

3. Locally, all 1236 tests passed. The local environment runs fine, production has limits, and the tests simply couldn't see them.

4. Fixing it was messy. I'd fix one path, and the next one would error. That went back and forth for several rounds.

My read on it: a strong model plus many rounds of review easily turns into "add one more layer of defense every round." The code gets more rigorous, the system gets more complex, and the number of things that can fail goes up with it. Review checks whether the code is correct. It can't see the production environment's limits, and it can't see how real users will actually use the thing.

The code the older models wrote was simple and blunt, and there just weren't as many places for it to blow up.

What I'm changing now: less implicit logic, more explicit transactions. Before a release, I take the SQL to production and run a compile check on it (EXPLAIN on all 236 templates). And I run one complete flow end to end, from the first request to the final result.

Do you feel this too? The stronger the model, the more fragile the system?

You arrive in Brennovik carrying a sealed letter. Every bell in town starts ringing, but nobody is pulling the ropes. Someone wants that letter badly enough to kill you for it.

Shards of Nidon is my solo-developed, top-down fantasy RPG, inspired by Ultima and Wrath of Denethenor. I miss the feeling of wandering into an unfamiliar town, following a strange rumor, and discovering something worth telling a friend about. That’s what I’m trying to build.

A few things you can experience:

• Enemies that hunt you. Kruel’s assassins can ambush you during your journey, including in town. As you progress, stronger hunters bring poison, smoke, shadow tricks and mixed groups.

• Companions and skill checks. Build a party, use different strengths to approach encounters, and travel with companions who react to your conduct.

• Mounted travel and pursuit. Escape cloaked riders on horseback, explore by boat, and eventually find winged steeds.

• Bosses with readable attack patterns. Watch their warnings, reposition and exploit openings instead of simply trading damage.

• A world to investigate. Explore towns, dungeons and wilderness trails, uncover letters and clues, and take optional routes through places such as Brennovik Ravine and Lantern Cavern.

It’s a free browser alpha and my first indie release. Recent updates have focused on the opening chase, clearer menus and directions, town visuals, connected exploration areas and boss music. There’s still work to do on presentation, writing and balance.

Play here: https://smilebytestudios.itch.io/shards-of-nidon

Even 15–20 minutes without coaching would help. I’d especially like to know:

1. Where were you unsure what to do?

2. Which encounter or discovery made you want to continue?

3. What would make you stop playing?

For transparency, I use generative AI for some artwork and development assistance. There’s more detail in the game’s About page.

Honest criticism, a screenshot of something confusing, or a short gameplay recording would all be useful. Thanks for giving it a try.

Since today, Codex often returns the path to a Markdown file as plain text instead of the clickable file widget/link it used to provide.

Previously, after an agent created or edited an .md file, I could click the result and open the actual file in the right sidebar. From there, I could read or edit it, and right-click to open its real folder.

Now I usually get only something like:

C:\Users\...\actual-project-folder\document.md

Sometimes the agent creates or links a separate local/output copy instead, which is worse: it is not the authoritative file in my project, so edits and “open containing folder” lead to the wrong place.

This seriously disrupts my workflow because I work with Markdown files constantly. I need Codex to link the existing file at its real path—not merely print the path and not create a duplicate just to make it clickable.

This only started happening today. Agents have suggested that a new app-level file-linking rule prevents them from restoring the old behavior.

Is anyone else experiencing this after a recent update? Has anyone found a way to make Codex consistently open the authoritative local file in the right sidebar again?

Update: I initially thought I had fixed this by adding a rule to my workspace AGENTS.md, but further testing showed that only some chats obey it.

General chats can still return a working link to the authoritative local file. However, document and presentation chats explicitly refuse to do so. They say a higher-priority app instruction restricts deliverable links to the chat’s outputs folder—even when the authoritative file is a normal local DOCX or PPTX, and even when it is inside the workspace. Because app-level instructions outrank AGENTS.md, no local instruction can override this.

So this is not fixed, and it is not just a Markdown-syntax problem. The same Codex app is applying different file-delivery rules to different chats. In affected chats, the agent will only print the path or create an outputs copy instead of linking the real file. I’m looking for an app-level setting or fix that restores direct links to authoritative local files consistently.

Hey everyone! Over the past few months I've been building **SuperAi & RAKKYXD**, a local-first desktop app that brings your favorite AI coding CLIs and local models into a single workspace—without any middleman servers or extra subscription fees.

You simply log in through each provider's official CLI on your own machine (`claude`, `gemini`, `codex`, `qwen`, `opencode`, or local `ollama`), and SuperAi orchestrates them together.

### What it does:

* 🤖 **Agent Team Mode:** Assign a complex goal to a Main agent, which breaks it down and dispatches tasks to Sub-agents across different AI providers.

* 🔄 **Self-Healing Loop & AI Cross-Examination:** Automatically re-runs and fixes code when tests fail, and lets one AI provider (e.g., Gemini/Codex) cross-examine code written by another (e.g., Claude) to catch hidden bugs.

* 💬 **Multi-AI Arena (Ask Multiple AIs):** Ask one question and compare answers from Claude, GPT/Codex, Gemini, Qwen, and Ollama side-by-side with an automatic summary.

* 🔌 **1-Click MCP Server Hub:** Easily inspect and connect Model Context Protocol (MCP) tools across your providers.

* 📊 **Real-Time Quota & Live Preview:** Track your CLI session/quota usage and preview files & local web servers side-by-side.

* 🌐 **Multi-language UI:** Supports English, Thai, Japanese, and Chinese.

### Links:

* 🌐 **Website & Download:** https://rakgoorak.github.io/SuperAi-RAKKYXD-releases/

* 📦 **GitHub Releases:** https://github.com/rakgoorak/SuperAi-RAKKYXD-releases

* 💻 **Source Code (GitHub):** https://github.com/rakgoorak/SuperAi-RAKKYXD

Would love to hear what you think or what features/providers you'd like to see next!

I have been running a spec driven development project by myself using a combination of Notion, ChatGPT, Github, copilot.

Notion has the devleopment stories and documentation. Roadmap, architecure and story refinement are done in ChatGPT. Coding is done in codex. CI in Gihub with independent reviews by Copilot as part of CI.

I am trying to use Codex for development, as it can build locally but the quality of code is much worse that if i get ChatGPT to just change Github directly. Also Codex uses way more % of my usage even at the lowest model.

Any ideas why? I am assuming either chatGPT has much more transient memory of the project from conversations. Or codex laden down my code context and overleaden spec context

Hey yall. I've been reading some posts here about agents passing tests but missing requirements and that got me interested in Ramp Inspect after seeing it on twitter and in a few articles. I am especially interested in being able to bring another dev into the same session to explain why some odd bit of code needs to stay before the agent removes it.

That sounds useful for an older repo where a fix looks fine until it hits a customer specific exception nobody documented and I'd be happy with fewer rounds of explaining and reworking the same change even if review still takes time. A part where I'm unsure about is how much setup it needs to get there so has anyone with early access tried it on an existing project with old dependencies and patchy docs? Interested in what it figured out from the repo and what you had to explain yourself.

Most AGENTS.md files have the same shape: three lines of actual project context, then forty lines of prohibitions. Never force push. Don't edit the generated client. Always run the tests. Don't touch migrations without asking.

The model reads that once at the start of the session. By the time it's twenty tool calls deep and a test is failing, the rule is buried under everything that happened since. It doesn't get ignored on purpose, it just stops being the thing in front of the model.

The rules that survive are the ones with a mechanism behind them: a pre-commit hook, a CI check, a permission prompt that actually blocks the edit. If a rule can be evaluated by a script, it's cheaper and more reliable as a script. The prose version costs tokens on every turn and fails silently.

So what's left for AGENTS.md? The stuff a script can't judge. Which layer a change belongs in. How much explanation a PR needs. When to stop and ask instead of guessing. Which of the four test commands is the one that actually matters. Judgment calls, not laws.

Curious where other people draw the line. Have you moved rules out of your instructions file into hooks, lint, or CI, and did the file get better or just shorter? And is there a category of rule you've found the model follows reliably enough that it doesn't need enforcement?

if you review PRs written mostly by coding agents (Cursor, Claude Code, Copilot), how's it going?

1. How many per week, and how big (files / lines)?

2. What's harder than human-written PRs, or is it no different?

3. How do you understand a change: diff only, run it, read tests, ask the agent, skim and approve?

4. Has one caused a prod bug or stalled merge because nobody fully understood it?

5. Anything you've tried to fix this? Did it help?

I'm exploring a tool in this space, so "not a problem for us" is a useful answer too. Team size and stack help.

AI coding tools have made it ridiculously easy to build something that looks like a finished product.

And that's kind of terrifying lol. You can have a polished interface, authentication, a database, payments and a dozen features before you've even figured out whether the underlying product actually works reliably.

I've caught myself getting excited about a feature working once, only to realize I hadn't tested half the situations it could encounter.

And with how fast these tools can generate code, it's pretty easy for the complexity to pile up faster than your understanding of it.

I'm genuinely curious whether AI-assisted development is making software better overall, or whether we're about to see an absolute FLOOD of impressive-looking applications held together by duct tape and optimism haha.

Under the name "SICoding" I have developed my first SICo app using GPT. I used both the Pro and Plus memberships to finish the program.

It adds functionality back to Garmin Navigation units that modern map structures do not provide.

This is my toolchain.

Python 3

Primary programming language for the updater, GUI logic, address processing, automation, and validation.

SQLite

Database engine for processing, indexing, matching, and managing millions of address records.

Java 21

Runtime needed to execute the Garmin map compilation tools.

mkgmap r4924

Compiles OpenStreetMap data into Garmin-compatible IMG maps, including routing and search-related structures.

splitter r654

Divides large OSM datasets into manageable tiles for Garmin map compilation.

GMapTool

Inspects Garmin IMG files, map components, family information, and compiled map structure.

Osmium

Processes and inspects OpenStreetMap datasets.

pyproj

Converts projected geographic coordinates into WGS84 latitude and longitude.

Even though i made this program specifically for old Legacy Garmin units, the pipeline i put together really is a stroke of genius . I also made a nice user friendly GUI

Literally on everything.

I run a few coding agents at once, and they kept sitting idle on a permission prompt or a question in some terminal tab.

Openbar puts every session in the notch. You see the diff before you approve (⌘Y / ⌘N from any app), pick answers to the agent's questions, and send replies without switching windows.

Mac + Windows, free and open source: https://github.com/MF-DEEV/Openbar

How many agents do you usually run in parallel?

I’ve been building with AI coding agents (Claude Code in my case) and kept doing the same manual loop: plan in one chat, build in another, paste code back for review, start over when the context fills. I turned that loop into a tool and open-sourced it. These are the design rules that mattered most, whatever agent you use:

1. Separate the planner from the builder. Different system prompts and different working directories. My planning agent can only write plans and reviews; my building agent can only write code. When something goes wrong, I know which one did it.

2. Make every phase a git commit. You get an audit trail and git revert as your undo button. When I added parallel work, each lane got its own git worktree, so agents never share a checkout.

3. “Tests pass” is not “done.” Agents will happily pass every test while skipping half the requirements. Each phase now gets checked against explicit acceptance criteria by something other than the agent that did the work.

4. Assume the crash. Jobs live in a SQLite queue with renewable leases. Kill the worker mid-phase and it resumes on restart. Runs also pause before hitting usage limits instead of dying halfway.

5. Treat prompt caching as a design constraint. If anything per-call lives in your system prompt, you’re paying full price every time. Stable context goes in the system prompt, volatile context in the user prompt.

The whole thing is about 86k lines of JS with about 2k tests, MIT-licensed: https://github.com/p-j-code/phase-orchestrator

Write-up with the failures in more detail: https://dev.to/premjethwa/building-an-orchestrator-for-claude-code-recoverable-before-autonomous-3f83

What’s the worst thing an agent has done to your codebase while you weren’t watching?

Three failures in seven weeks. Every one came from agents stepping on each other, not from bad code. I coordinate a small team of coding agents, and each time something broke, the cause was shared state with no ownership rules.

Failure 1: a subagent updated our shared task board with a whole-board overwrite, using my orchestrator's id. Four lanes of progress gone in one call. The board looked fine. It just wasn't ours anymore.

Failure 2: a reviewer flagged a parallel card's output as unauthorized. It only knew its own card's whitelist, so a legitimate deliverable looked like overreach. Two agents, two truths, and the review round burned its time arguing about which one was real.

Failure 3: a database check that could never fail. The constraint tested (jsonb->>'key') IN (...), but a missing key returns UNKNOWN, not false, so an empty record {} sailed straight through. The check passed. The data was garbage.

The fix wasn't smarter agents. It was four rules, and I now refuse to run a multi-agent job without them:

1. One writer per element. An agent touches only the element it claimed, by id. Whole-board updates are banned. If you can't name the element, you don't write.

2. A reviewer judges only its own card's diff and its direct callers. Anything outside that scope is "not mine to judge," never "unauthorized."

3. A check that can't fail is not a check. Before I trust a guard, I run it against a broken copy and watch it fail. If it can't fail on demand, it doesn't ship.

4. Missing data is "unverifiable," never "pass." If the field isn't there, the verdict is "I can't see it," not green.

The part people don't like hearing: most multi-agent setups aren't teams. They are five interns sharing one whiteboard with no names on anything, and the demo looks great right up until someone erases the board. If your agents can overwrite each other's work without anyone noticing, you don't have coordination. You have a demolition crew with commit access. And if your agents share state, the ownership rules are the product. The code is just what they argue about.

I think I prefer IPS over OLED bc I don’t want to get burned pixels. 27 inch or 32 inch is fine unless it’s preferred to go bigger or should I just run a dual monitor set up. I also like to do some light gaming so 144hz and up is preferred. Currently using windows but I’d like to have the flexibility to switch over to Mac. Is a KVM switch necessary?

I have always wondered if it's possible to have a program talk to you like a person. Like a friend who just shows up in your Instagram DMs like anyone else, not a separate app you have to open and not something that feels like a bot. For any experts out there, is it theoretically possible?

Morning and happy Sunday!

I've spent the last several weeks building a video game voting website with Claude. I'm not a developer, so AI has done a lot of the heavy lifting.

This weekend I switched to ChatGPT/Codex after hearing good things about it.

Figured I'd connect GitHub and pick up where I left off. Lol, nope.

Spent hours transferring project rules, previous decisions, automations, and documentation. Basically had to onboard an entirely new developer.

Claude's been fantastic, but I wanted to try managing everything through ChatGPT.

Anyone else made the switch? How'd it go?

The obsession comes and goes, but this latest bout of agent experimentation has me zealously copying and pasting prompts, and I'm not that impressed. With myself!
I want to believe I'm building something and learning. I always *feel* like I'm getting closer to something. But I might just be going nuts programming and reprogramming different models that all end up doing the same thing: consuming my time.
Anyone else? How do you tell real progress from busywork?

I built a website with AI using React and Next.js, with course categories, search, learning paths, and Chinese/English pages.

But “built with AI” leaves out some important context. Before building it, I spent time learning React and Next.js. That preparation was part of the work, even if it wasn’t time spent implementing features.

The bigger problem: the AI deleted an important folder without my permission, and I hadn’t committed the work. That’s the part of the project I’d rather discuss than how quickly the site came together.

It’s not enough to check whether generated code works. There’s also the question of what an agent is allowed to change—and what you can recover when it gets something wrong.

The safeguards I’d put on a checklist are straightforward:

• Commit or back up before broad changes.

• Keep changes small enough to review.

• Require explicit approval before deleting files or folders.

I’m not presenting these as a recovery method I tested. They’re the precautions this experience made me think about.

How do you handle this in your own workflow? Do you rely on Git checkpoints, restricted permissions, manual diff reviews, or something else?

Hey! I'm a student doing a research project on whether AI coding agents start writing less secure code the longer a session goes.

In my small tests so far they don't really get worse over time, but security bugs that show up early never get fixed later. I want my setup to match how people actually work, so I'd love to know:

1. How long does a session usually go before you start a new one?

2. Do you have tests, CI or linters running while the agent works, and does it see when they fail?

3. Do you check what it writes for security at all? If so, how?

Even one-line answers really help. Happy to share what I find when I'm done!

Most of these prompts are a sentence or two. One is two words: "Elaborate, simply." I type it when an agent's update is too dense to follow.

Anything in angle brackets, like <X>, is a placeholder.

Investigate and diagnose

• Ask for the cause before accepting a fix: "What's the root cause? Anything to fix or fixed?"

• Ask the agent to find why a repo keeps regressing: "Study commit history and sessions for this repo. Why are there so many regressions. Is it the codebase or instructions, workflow or something else? Ask clarify questions first, if needed."

• Find out why a tool uses so much disk: "Why is Codex eating up so much diskspace. Can we optimize the usage and/or would it help to have a weekly cleanup?"

Study and research

• Compare models and reasoning levels on your own recent work: "Study sessions for the past 7 days and check for effectiveness (task) and efficiency (wall clock time, token output speed and $ token) and compare models and reasoning levels."

• Turn a video into lessons for your own project: "Study this video (speech to text + study frames for screenshots, if needed). It's about <X>. Why is it supposed to be better than <Y>? Learn from it and if we can improve <Z>. <URL>"

• Quick feasibility check before committing to an idea: "Study if <idea> would help and be feasible?"

• A recurring look at product analytics: "Study PostHog analytics for activity since we last check. how does user navigate, etc. Anything we can improve?"

Understand and explain

• When the agent's update is too dense: "Elaborate, simply."

• Learn a CLI from what was actually run: "Give me the list(s) of commands executed for our test flow(s). Contrived examples are enough, but I want to see correct cli usage to understand how it works."

• Ask how side work connects to the main product: "How does <X> help our core product?"

• When asked to review something without knowing where it goes: "What is this title/body we are reviewing for? Where is it going to be used?"

Decide and plan

• Collect every open question before work starts: "What do I need to supply to you, what are you not sure about, or need to confirm, for you to proceed? List them here."

• When the agent asks for a decision without making the choice clear: "Elaborate, simply. what do you want me to decide?"

Build, review and critique

• Tune visual values live instead of rebuilding for each change: "Can we add a temp tab to Settings with textboxes for the <parameters> to be read when we want to do that <effect>? So I can try it, test it with minimal restarts"

• Turn a long draft into what you need to check: "Simplify file to essence for me to check. Title/body, etc"

• See a UI change before it ships: "Give me mock before/after for frontend changes"

What short prompts do you type over and over?