🦄 Thanks @francistrdev for starting the conversation that really got me to thinking about this idea in the first place. I started truly working wi...
For further actions, you may consider blocking this person and/or reporting abuse
Good list! I know @codingwithjiro does number 5 in which he use AI to teach him English and vocabulary, which is a great way of learning in my opinion.
I do suggest adding some images to lighten up the post if you want. Can be any images and doesn't have to be professional or anything. Just something to be more engaging :)
Thanks for the mention :D
You know, I thought about images yesterday. By this morning I had forgotten all about it. Thanks for the tip!
The adversarial review model is the part that actually holds up — one AI reviewing another's output with no shared context tends to catch a different failure class than self-review, which is the same reason running two static analysis toolchains over the same PR surfaces more than running one twice. The 134 standing rules framing resonates more than the tooling choice, though: declaring intent upfront rather than patching behavior in the moment is the same instinct that makes linting rules more reliable than runtime guards. One thing I've hit with large rule sets is that they quietly drift when the underlying models update — do yours need a refresh cycle, or do they tend to stay stable across model versions?
I haven't ran into a whole lot of drift over models, but its hard to utilize the built-in memory features across tools. The whole problem with my current setup is that I have to duplicate rules between Claude and Codex and Copilot mostly gets left out. When I pull in anything else then they're starting blind. I'm sure there's a simple solution for this—like the skills I have linked currently—I just haven't explored it much yet.
I haven't fully solved this either, but here's a mechanism worth naming: the drift isn't in the rules text, it's in enforcement surface. Claude and Codex both read markdown context files, but neither validates that a rule was actually followed — they just re-read it each session and hope. So duplicated rules don't even stay duplicated, they stay duplicated-and-silently-diverging as you patch one and forget the other. I moved toward making violations fail a lint/CI check instead of living in prose, which at least makes the drift loud instead of quiet. Copilot getting left out is real too — it doesn't consume the same context format at all, so anything markdown-based only ever covers two of your three tools.
The one exception to this is if you have something like
AGENTS.mdand manually point all tools at this one file as a baseline, but its not a perfect solution... I do have a strict set of commands and CI checks in GHA, including Semgrep and Sonar. Those do help a lot! I've played with a few others, but those are the main ones that have survived long-term.You're right that a single baseline file doesn't get you compliance, only a default — every tool still has its own override surface, and the moment someone passes a flag or a different agent ignores the convention, AGENTS.md is decoration. The gap I've hit with Semgrep specifically: it's fast at syntax-shaped bugs but blind to anything requiring type/data-flow context across files, so SQL built via a query builder three functions removed from the string concat won't trigger a rule tuned on the concat pattern itself. Sonar's dataflow engine catches more of that class but drowns you in low-confidence noise on anything metaprogramming-heavy. Neither replaces someone reading the diff — they just move where your attention goes.
I just forbid all Sonar issues of any kind Noise or not, I don't want to see them so the agents handle it 😆 It does introduce a certain level of anti-YAGNI in the code, but I'd rather that than the alternative. I agree that there's no single tool that can handle everything. I keep those two plus the GitHub scans turned on for everything that AI codes. It's not failsafe, but a lot better behaved than not having them present.
Ashley, thank you for this piece. It is one of the most honest and practical accounts of working with AI I have read on dev.to. The 134 standing rules framing is genuinely fresh — you are not theorizing about AI workflows, you are documenting a system you actually built and live in.
One thing that resonated deeply: Your point about restarting instead of repairing. "If you've told the model the same thing three times and it's still wrong, then assume your conversation is poisoned." I have been that person arguing for another week to rescue something that started broken. The three-failed-corrections trigger is a cleaner rule than anything I had. I am taking that one.
Two takeaways I am carrying forward:
One suggestion: The permission model (blacklist over whitelist) is powerful but the post does not show what a standing rule file actually looks like in practice. A follow-up with 3-4 real rules from your 134 and the failure that produced each one would make this approach concrete enough for others to adopt. The Carbon Trace / Codex vs Claude lifecycle invariant example is great — more of those would make this a reference post, not just a great read.
Genuinely impressive work. The competition wins speak for themselves, but the process behind them is the real proof.
Thank you for such a thoughtful reply, it's much appreciated. I put together a few examples for you or anyone else who wants to steal them. 😃
→ Gist Link
BIG - Thank you!
The distinction between independent review and manufactured agreement is the strongest point here. In the agent and MCP workflows I have been building, I have reached a similar conclusion: a second reviewer should receive the branch, the invariants and the risk — not the first reviewer’s verdict. Otherwise, it is very easy to create consensus without increasing coverage. I still keep the acceptance criteria and business-risk decisions human-owned, but separating implementation, review and final validation has made the process much more reliable.
I agree that the AC should be human-owned along with the general design specs—besides that's the most fun part for me. 😃 It's good to know other people are reaching the same conclusion. Thanks!
Exactly — the design and specification side is where human judgment creates the most value for me too. Once the boundaries and acceptance criteria are clear, agents can move fast without owning the product decision. Thanks for the thoughtful exchange!
Hi Ashley,
I completely agree with this! Humans reviewing code at the end of a long day with tired eyes are bound to miss things. AI is great at catching subtle bugs and suggesting best practices that we might overlook when exhausted.
That said, it’s not always 100% right—sometimes it suggests "best practices" that just add unnecessary complexity to the codebase. But overall, it really is a great coding companion.
We actually used to rely on Gemini for code reviews, but since we hit the free plan limits, we’ve switched over to Claude. Loving the workflow so far!
I like Gemini as an LLM. As an agent though, it leaves much to be desired. I totally agree with the "best practices" statement too, which sometimes is just easier to leave it in than argue the fact that YAGNI. Which is another reason to also let the AIs handle the reviews. 😆
yes i agree with you 😁
Core Summary: Modern AI development isn't about writing code alongside an assistant; it's about delegating tasks, enforcing boundary permissions, using AI for cross-examination, and converting mistakes into permanent systems.
Great summary! The more we as devs build the self-checking systems into everyday AI processes, the less traditional knowledge is going to matter. And I think your ability to use AI effectively without becoming the bottleneck in the whole process will become much more important as time goes on.
right!
I really liked the point about moving the decision-making earlier rather than simply trying to save time. That's been one of the biggest shifts for me too. AI doesn't always reduce the amount of work, but it often improves the quality of the first draft and gives me more time to focus on reviewing, refining, and making better decisions. Used that way, it's become more of a thinking partner than just a writing tool.
This is so true! I've always coded in rules to have AI challenge me instead of blindly agree to what I say. I have lots of ideas and not all are good ones. 🤣 It helps with iteration, like you said, to prove an idea (or not) earlier in the process.
The second-reviewer rule deserves its own post. Handing reviewer two the first reviewer's verdict is the same reason you don't show a witness a photo before the lineup — you haven't doubled your coverage, you've just made the second opinion cheaper to reach. And the 134-rules log reads less like a safety system than like version control for your own management decisions, which might be the most underrated part: the failures got converted into assets instead of vibes.
The witness lineup analogy is a great way to look at it, because that's exactly what happens. And a lot of the project rules do read that way, though I hadn't really looked at it like that before. Thanks for the perspective.
Having the model interview me in a similar manner has drastically changed my outputs. Having ADHD affects my memory, and I can be two responses from the original request and have completely forgotten what I've prompted and I'll start dropping details on my side.
That really comes from IRL managing a kitchen training newbies. I'd always tell them that I'm scattered and will def. forget to tell them things so ask many questions. There are a few things in my instructions I pull from my 'checks & balances' when I'm out touching grass, though not many come to mind right off.
It's interesting the parallels between memory and context management with a brain like mine that's stuck in manual mode and an LLM model with limited context to begin with. The self-help books even read about the same, lol.
Great post, I got a lot from it!
I was absolutely guilty of forgetting where I was at counting yesterday—and I only had to get to two... The struggle is real! 🤣🤣 AI is really handy at remembering things for you when you need it to and its much better than I am. Glad you enjoyed the post.
Two of your nine landed hard because I have the scars to match — I run an autonomous revenue-plan executor (30-min time-boxed, lockfile-guarded) that reads a standing-rules file at the start of every session.
Rule #6 (corrections to permanent rules): My most load-bearing rule is a lockfile guard — check
.revenue_plan.lockbefore each run; if it exists and is <35 min old, exit immediately. Written in blood: overlapping autonomous runs caused an 18% failure rate (two sessions mutating the same plan file). Same shape as yourpush-only-when-explicitly-told— a failure that became a prohibition.Rule #7 (proof beyond "tests passed") is the one I wish I'd internalized earlier. I built a macro scenario classifier tagging ISM PMI releases. Its output "passed" every sanity check — scenarios produced, numbers matched my priors, the summary read convincingly. I shipped it to 3 platforms. Then I ran the actual proof: a real event study (72 releases, 1530 trading days, p=0.643). The signal was backwards at all 4 horizons. The classifier's output was a test built on the same mistaken assumption as the classifier itself — green lights everywhere, wrong layer. Exactly your clipboard example, with money on the line.
The question I'm sitting with: when the autonomous agent writes its own progress log, how do you keep it from becoming an echo chamber? Mine records "action completed" every session while the actual success metric stays flat. The log passes its own "tests" (entries well-formed, actions happened) while proving nothing about whether the actions mattered. Do your 134 rules address the meta-level — auditing the value of the work the rules produce, not just compliance?
No, I haven't tackled this meta problem yet though I've definitely been thinking about it. I think the Repository Intelligence Architecture (RIA) is on the right track with this though. There's a few repos out there with decent implementations, but nothing I've had a chance to dive deep with yet. Let me know if you wind up using any of it though. I'm curious to see what it looks like in practice.
The standing rules over permission spam part resonates hard. Where I push back is on cutting human review of the change itself. AI adversarial reviews catch a lot of nits and pattern matches, but they still miss the quiet wrongs: a deleted invariant, a renamed field that still typechecks, a migration that only works on the happy path. I design the system the way you describe, then I still read the actual diff against the original ask before I trust the stop point. The end result can look right while the path rewrote something I never intended to touch.
I would argue that every single one of those things would be caught anyway in a good validation pass. You can execute the code and know if its functioning properly based on behavior alone, except maybe for a renamed field. Which isn't the end of the world when you're no longer the primary audience.
The part about turning mistakes into permanent rules is what I found most useful here.
That’s basically the difference between asking an agent to fix a bug and actually improving the development workflow around it.
The multi-model review approach is interesting too, especially when each model is given the problem independently rather than just reviewing the previous model’s conclusion.
I’ve been working through similar patterns while building our [All-in-One AI Masterclass , particularly around using different tools for different parts of the development process.
The “restart instead of repair” rule is probably one I need to use more often myself.
Thanks for your insights! The biggest problem I'm running into currently is I forget which rules are in my personal setup versus my work one. Same is true of how do you scale memory from one user to a team of users. That solution is my next goal, just as soon as I have time to research...
"AI review is smart reallocation of work to where the work belongs" — this is the frame I've been missing. most pushback on AI code review stays at "can AI catch the bug?" but the real argument is cognitive allocation: two adversarial reviews targeting a specific change catch more than a tired human scanning a diff.
we've been moving the same direction. the rules as memory pattern (your 134 standing rules) is more reliable than context window prompt engineering past 30 or 40 accumulated decisions. the system remembers what the human forgets to prompt.
the piece I'm still wrestling with: rule accumulation without pruning eventually produces contradictions the AI resolves silently. curious if you've hit that, and whether you have a process for auditing which rules are still load bearing vs legacy?
I've had AI perform self-auditing passes a lot like the data mining I describe in the post. The biggest changes the first couple of passes were project rules moving to a user scope and conflicting project rules being removed altogether. I think with legacy that latter one is going to be the worst offender, especially as the dev goals change over time.
For larger projects, I like the idea of having everything recorded in an
AGENTS.mdfile, just because those are easier to review than local memory files. AI reads it the same way, it's just a little harder to keep in sync (fixed with a skill). The upside is that you can check everything into the codebase and sharing becomes much easier.Hope that helps! Thanks for reading 😀
"None of this made me faster, it moved the deciding earlier" is the whole piece in one line. Rule #2 is the sharpest, handing reviewer two the first verdict is just agreement with extra steps.
Thanks. Glad you enjoyed it!