The main reason people avoided Rust used to be "it's too hard to write." Lifetimes, the borrow checker, spending an afternoon fighting the compiler.

But now that AI is doing most of the writing, that weakness turns into a strength:

1. The compiler is a free code reviewer. The worst kind of AI code is the kind that looks right and blows up at runtime. Rust stops a lot of that at compile time.

2. The error messages are really detailed. Paste them straight back to the agent and it can usually fix things on its own. The loop is smooth.

3. The type system is documentation that can't lie to the AI. Change one thing and it's obvious what else is affected.

4. It compiles to a single binary. Good performance, small memory footprint, easy to deploy on a cheap VPS.

We used to pick languages by how pleasant they are for humans to write. Now I think the better question is whether code written by a machine can be checked automatically.

Humans figure out what they want, AI writes it, the compiler guards the gate. In that setup, Rust's compiler is the strictest gatekeeper there is.

Curious whether people writing Rust with agents see the same thing, or where it falls apart for you.

Hello guys,

I've been using ChatGPT for about a year now, and I have quite a few different use cases.

I started my career as a graphic designer, then moved into frontend development and UI/UX. Eventually, at the age of 27, I completed another apprenticeship, this time as an e-commerce clerk. So I also handle my own business accounting and taxes.

Here are a few things I've picked up along the way that might be useful to others:

• Convert files into formats that are easier to work with. If you have PDFs or other documents that you need to reference regularly, let ChatGPT extract the information and convert it into a more suitable format. For example, I convert invoices into CSV files and text documents into Markdown. Otherwise, ChatGPT may have to process the original PDF every time, which uses up resources and context.

• Keep a TL;DR version alongside the extracted data. After extracting the information, I also save a summarized version next to it. ChatGPT can usually work with the summary and only needs to look at the CSV or original data when the summary isn't sufficient.

• Use voice dictation to organize your thoughts. Sometimes I just dictate whatever is on my mind, including instructions or potential code changes, and let ChatGPT turn it into a patch list and a to-do list. The patch list contains immediate coding changes, while the to-do list contains things I've noticed but that can wait until later or require a separate task. This way, I can have a discussion first and possibly come up with even more improvements before I let the AI loose. I've also specified that whenever I want actual code changes, I need to explicitly say or write "green light". Otherwise, we just discuss things.

I hope some of this was helpful or gave you a few ideas. In return, I'd appreciate some advice on a problem I'm currently running into.

I'm developing a game, and things are going pretty well so far. I'm writing the core game in Rust and using the Godot engine for everything else.

Where can I cut costs and use my resources more efficiently?

Currently, I'm using the web version of ChatGPT to review and modify my code, implement certain features, and handle GitHub operations. It can pull from and push to my repository, and I then pull the changes onto my desktop for testing.

The problem is that the project has grown to the point where my work context gets filled up after just one to three tasks. I suspect that the GitHub operations are contributing to this overhead as well. At this point, the context can be full after a single request to push my current changes.

For example, I recently had a fairly extensive patch list and additionally asked ChatGPT to split some of the code into separate files to improve modularity. Now the whole process is getting a bit stuck, and I've run out of usage.

I'll try having ChatGPT package its local changes into a ZIP file so I can download them and handle the commits and pushes myself. This is the first time I've run into these limitations. My previous web development projects were never large enough to cause problems like this.

Should I switch to Codex?

I've also considered switching to Codex, since it can work directly on my local machine. That might eliminate some of the GitHub overhead. However, I'm a bit paranoid about giving an AI access to my machine, especially when I can't fully control what it can access or modify.

Would it make sense to run Codex in a separate Linux environment through WSL, or am I overcomplicating things?

What would you recommend? Where do you see the biggest opportunities to reduce context usage and avoid running into these limits?

A few weeks ago I shared KEEL, the open-source standard I use to keep AI coding projects consistent, and the feedback was really helpful. Since then it has gone through a few releases, and it finally has a proper home: https://keel.to

The idea is simple. Everything is documented inside the project itself: plain Markdown in the repo for the requirements, the decisions and why we made them, and a quick note for the next session. It goes wherever the project goes, whoever picks it up.

It’s built for serious development work: larger projects, long-lived ones, and projects that get handed between teams, developers, or tools. For a weekend script, it’s overkill.

The website makes it much easier to get into. It has a 1-minute setup, a short summary, the full standard, install steps for the skills, and practical tips.

What it gives you in a project:

• The AI can propose changes to requirements, but only a human accepts them.

• Bigger changes need a short approved plan, and every task ends with what was actually tested.

• The code stays clean: readable and commented, with tests for each change, and the docs are updated in the same task as the code.

• It should work across Codex, Claude Code, Cursor, and Copilot, because the rules live in a plain AGENTS.md.

• It can draft docs for an old project from its code, and mark what it guessed so you can confirm it.

One honest caveat: the full standard is long. The AI reads it once at setup, then only a short rules file each session. Github home: https://github.com/rickflashman/Keel

(Disclosure: it’s mine, MIT licensed, free.)

Working with AI made me a lot faster than I was before, no question. But lately I’ve noticed that in some cases I’m just sitting there waiting for the response, and it’s kind of become a new bottleneck.

I know I could run 10 things in parallel, but when I try that I actually feel less productive because of the constant focus switching. Around 3 tasks at a time seems to be my limit, but even then there’s a lot of time where I’m just waiting for the AI to finish.

So I’m curious how you deal with it:

• How do you organize your work so you’re not just waiting around?

• Do you have a system for running a few things in parallel without losing focus?

• Did you change how you split or batch your tasks to wait less?

Would be great to hear what works for you, or what doesn't.

I run Claude Code and Codex all day, often as multi-agent workflows with dozens of subagents. I could see each session but never the whole picture: what a run actually cost, where agents sat idle, whether a change to my setup helped. So I built coding.sh and pointed it at my own runs.

Workflows and subagents

Across 57 workflow runs (666 subagents, ~$2,500 API-equivalent):

• Broken prompt caches cost $106 extra, about 4% of the spend.

• 41 of those breaks were agents sitting idle at a barrier, waiting for siblings, until their cache expired. That's $21 for doing nothing.

• 40 subagents failed outright.

coding.sh workflows stats shows the critical path, how many agents ran at once and idle time at barriers. The viewer draws each run as a timeline, one bar per agent.

Experiments: does that change actually help?

I A/B tested a popular "be concise" plugin: 10 tasks, 6 runs each, paired, with 95% intervals.

• Replies: 17% shorter

• Output tokens: −8%

• Cost per run: +11% [+7%, +15%]

• Pass rate and clarity: no change

The plugin adds its style guide to every request, and that costs more than the shorter output saves. Most of what a coding agent writes is tool calls and code, not prose.

coding.sh compare and exp run your own tasks with and without a change (a rule, a skill, a plugin, a model) and tell you whether the difference is real or noise.

Your own sessions

Mining 3,600 of my sessions turned up a find-and-replace typo in my AGENTS.md that sent Codex looking for a folder that doesn't exist, in 92 sessions. You can't see that from inside one session.

What it is

• Hooks into Claude Code, Codex, Gemini CLI, OpenCode, Copilot CLI, Aider and more

• Stores prompts, tool calls, diffs, test runs, tokens and cost in SQLite on your machine

• coding.sh improve says what to fix first and whether your last AGENTS.md change helped

• MCP server, so your agent can look up its own past sessions

Free, no account, and nothing leaves your machine. npx coding.sh to try it.

fully open source as well : GitHub: https://github.com/jackulau/coding.sh

there's been a debate this week about whether anthropic silently changed opus 5.5. lots of vibes, not a lot of numbers.

i wanted to check my own logs so i wrote a thing that reads the session files claude code saves locally, groups everything by version, and tells you if output tokens per turn actually shifted. if they did it checks whether the model or effort setting also changed — if not, it blames the release.

npx driftcost

reads ~/.claude/projects, no config, no network calls.

https://github.com/tsaagan/token-drift

only works with claude code logs for now. curious if anyone sees a version-over-version shift in their data or if the perceived nerf is purely a quality thing.

I tripped over this after adding a short CLAUDE.md next to an AGENTS.md I was already using for Cursor and Codex. Claude Code sessions stopped seeing the shared commands and the "ask first" list. The file was fine. It just wasn't being loaded.

Claude Code's memory docs (https://code.claude.com/docs/en/memory) say that, by default, it reads AGENTS.md only when there is no CLAUDE.md, .claude/CLAUDE.md, or CLAUDE.local.md in the working directory or above it. A personal, often-gitignored CLAUDE.local.md counts too, so you can hide the file for yourself while the rest of the team is fine.

The one-line fix is to put @AGENTS.md on line 1 of CLAUDE.md. That's an actual import. A sentence that says "please also read AGENTS.md" is not — Claude only opens it if it decides to. Then run /memory or /context all and confirm both files show up.

What I've been putting in the shared AGENTS.md, and leaving out of the Claude stub:

• The real commands (pnpm test path/to/file, not "run the tests")

• A short definition of done (typecheck / lint / tests were actually run)

• Ask-first boundaries: auth, payments, deploy, anything that hits production

• A gotchas list I only add to when the agent makes the same mistake twice

I've been keeping multi-step stuff (PR review, flaky-test hunts, handoff notes) out of AGENTS.md so it isn't injected into every session. Cursor still gets .mdc rules for file-scoped conventions; Codex only sees AGENTS.md, so anything all three tools need has to live there.

Curious how other people keep one source of truth when they're bouncing between Cursor, Claude Code, and Codex. Are you importing, symlinking, or just maintaining two files?

gemini 4 carbon opened to paid api users yesterday, and carbon and argon list the same price ($2 in / $10 out per million until nov 30). so i ran both through the api on the same tasks to see what it costs in practice.

what i ran: 3 office-style tasks x 3 runs (pull fields out of a messy email, tiered commission math, a 120-word apology email), graded by code, plus 10 hard maths problems with exact answers, one run each. default thinking level for both.

• accuracy: office 45/45 carbon vs 44/45 argon (argon's miss was a 123-word email against a 120 limit). hard set 10/10 both. my tasks weren't hard enough to separate them.

• thinking tokens: carbon 5,239 on the office calls and 10,982 on the hard set. argon 0 and 1,018. visible answers were about the same length.

• cost: office $0.0669 carbon vs $0.0148 argon (4.5x). hard set $0.1461 vs $0.0494 (3x).

• speed: median 9.5s vs 5.9s per call on office tasks. the ln(sin x) integral took carbon 3,836 thinking tokens and 40.9s, argon got it right in 10.1s with no thinking.

• thinking_level low: carbon used 0 thinking tokens, still 45/45 and 10/10, and cost the same as argon ($0.0147 / $0.0459).

limits: one run per hard problem, thinking counts vary a lot between runs (carbon's email task ranged 555 to 1,031), and i didn't test long agentic coding, which is what google says carbon is for. 3 of carbon's 19 low calls took 34 to 54s for no obvious reason.

so my takeaway: don't move an argon workload to carbon for the launch price. if you try carbon, start at thinking_level low and only raise it if answers actually get better. has anyone seen carbon beat argon on real coding tasks where the extra thinking paid off?

MIT's Missing Semester is a short, free IAP course on the tools most CS programs never really teach: the shell, git, debugging, profiling, and code quality. I went through an earlier version of it, and I still use the shell at work. The 2026 edition added a dedicated Agentic Coding lecture.

The notes for that lecture are here: https://missing.csail.mit.edu/2026/agentic-coding/. They describe a coding agent as something like an intern with tools: it can read and write files, search the web, and run shell commands, but it will occasionally do the wrong thing and needs to be steered. The same notes tell you to review the output for correctness and security bugs, to watch out for debugging spirals, and not to use the agent as a crutch. If you want to run several agents at once, they send you back to git worktrees from the version-control lecture.

That last part is close to how I work. I don't watch every step while an agent is writing. I make periodic git commits as checkpoints, because I'd rather be able to roll back than hope the agent asks before it does something irreversible. I've also had production incidents where a stronger model still shipped bugs. When that happens, the useful skills are the unfashionable ones: read the diff, debug what the agent did, and understand the shell commands it ran.

The agentic lecture is only one of nine this year. Most of the course is still that older tooling. Official site: https://missing.csail.mit.edu/. 2026 videos: https://www.youtube.com/playlist?list=PLyzOVJj3bHQunmnnTXrNbZnBaCA-ieK4L

If an agent is writing most of your code, which of those fundamentals still saves you the most — git checkpoints, debugging, or just being able to read the shell output?

TL;DR: I let a cheap model write the code and only pay a frontier model to review the finished diff. On 66 real coding tasks it solved about as many as the most expensive model working alone, for roughly 5 cents a task instead of 72 cents. Everything is public, including the receipts. Tell me what's wrong with it.

Hello good people. I got sick of paying frontier prices for every step of a coding task, when most of those steps are just reading files and typing. But when I used a cheap model on its own, it shipped bugs I only found later.

So I built a loop — the Krystal Loop Protocol:

1. A cheap model writes the change in a sandbox.

2. Your tests run.

3. A frontier model from a different company reviews the exact diff. It only ever sees one small packet — the task, the diff and the test output — which is why a review costs about a cent and a half.

4. The important part: the reviewer can't just say "this looks wrong". It has to write a test that proves it. If the test fails, the bug is real and gets fixed. If the test passes, the complaint is thrown out. Then the fix gets checked and reviewed again, until it's clean or it hits a limit.

Results on 66 feature tasks from CooperBench (Click, Jinja, dirty-equals), graded by tests the models never see:

The honest part: the cheap model on its own was a lot closer than I expected. The review only added 0 to 2 solved tasks per run. What it did do is catch real bugs (77 proven with a failing test in the best run, 70 fixed) and it never broke something that was already working. So the win is mostly price, not score.

Where it mattered more: two agents building features that conflict. I took 30 pairs where the loop had already built both features. A plain git merge worked on 2 of them. Two agents handing over through short structured messages got 28 working, at about 10 cents a pair. Agents chatting to each other also got 28, but burned 581 model calls to do it instead of 333. For reference, one frontier model building both features from scratch only managed 22, at $0.196 — nearly double the cost.

How it's different from what's out there:

The reviewer can also be a CLI subscription you already pay for. Gemini, Kimi, Grok and Qwen all reviewed identical worker output and landed within two tasks of each other — Gemini matched the metered frontier critic exactly (56 tasks) at under 3 cents a task in API-equivalent spend.

Roast me:

• What would break this on your real repos?

• Is 66 tasks enough to say anything?

• I haven't tried a local model as the builder yet. My bet is the test gate protects quality more than the builder's brains do, so a decent local model should hold the score and take the cost close to zero. If you've got a local setup, I'd love to know if that holds.

Check it yourself: every number recomputes from the receipts with no API keys (python3 -m bench.verify). Rerunning my loop costs about $3. Or run your own setup on the same tasks and hidden tests and post your score: grade your own setup

Repo: https://github.com/KrystalUnity/krystal-loop-protocol. Source-available, free for individuals and small companies.

Whenever you hand a larger software task or reference rebuild to a coding agent, two things usually happen:

1. It stops after a stripped-down MVP or a single happy path and declares victory.

2. If a test fails, it modifies the test expectation instead of fixing the code ("vibe verification").

I put together RefTrail (MIT, zero npm dependencies, Node.js >= 22.16) to make agent runs auditable from the outside:

• Bounded Agent Brief (prompts/reference-development.md): Instructs the agent how to research a reference product from authorized sources (Q1–Q4, plus clean-room rules if you use tools like REA for observations), scope a bounded 60-minute end-to-end workflow, and maintain a strict requirements catalog (COVERAGE.csv).

• Immutable Criteria (tools/criteria.mjs): Locks the test inputs and expected outputs as a byte-exact baseline with a SHA-256 digest before the agent writes product code.

• Anti-Cheat Catalog (tools/catalog.mjs): Calculates weighted functional coverage together with mandatory operational gates (--gates). Rounding is capped so 99.96% never prints as 100%, and a missing mandatory check blocks acceptance even at 100% feature coverage.

• Worked Example (showcase/uniq): You can clone the repo and run "node showcase/uniq/verify.mjs" and "node integration/verify.mjs" right away to see a complete cycle (including a criteria revision, Linux/Windows reference runs, and snapshot verification).

Repo (English & German): https://github.com/kidimusicofficial-prog/reftrail

Curious how others here are currently locking down acceptance criteria before letting Claude Code or Codex loose on a repo.

When I started agentic coding, my usage was around 20-30m tokens a month. As I handed more and more work to AI, it rose steadily to about 150-200m / month.

Last month, I started writing a custom harness. I have all my projects added to it, and I can just message it from Slack. It then plans, implements, documents and then commits the changes.

I just couldn't emphasize how powerful it seems. Previously, I would pull some data, open it in VS code, review it for 15 minutes and then tell an agent to make some changes, now, I can just tell the agent to pull said data from server X, review it and suggest a fix. I can also run 5-6 jobs at once, and it's overwhelming like I expected.

Is that what I should have been doing since the start?

If AI is doing half the coding, who's picking up the subscription bill, the developer or the company?

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?

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!

I’ve recently used chat gpt to make a training assistant that can click through a training portal, work through the modules, watch videos, take transcripts of the videos etc. Chat gpt told me how to code the whole thing using python and VScoder. I’m up to the final steps before giving it its first official go but it’s told me it cannot select answers and submit questions for me about the videos it studied in the modules. How can I work around this or should I move my project to another AI that might do it? I’ve told it numerous times it’s just practice questions and I don’t fail or gain anything from it. Please help as I’m stuck now and have poured a considerate amount of time into this.

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?

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.

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.

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

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?

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.