> Can you just give an agent a desired outcome and let it work, unsupervised? Absolutely not.
Ignoring instructions - whether in AGENTS.md or my prompt - is the worst of it, and it routinely happens. It just waives things that I explicitly told it to do as part of the design.
Vibe coders (in the true sense, zero oversight) claim that you just need to prompt it carefully. That's completely untrue when faced with your careful prompt being ignored.
I even have "don't overrule me without asking" in my global AGENTS.md, and it simply doesn't do that.
These are word generators, not agents, I’m really not sure why people think they could be capable agents (ie independent) when they consistently ignore instructions, generate the wrong things and then double down when questioned, etc etc.
You’ve been sold something that simply doesn’t work for the purported use case (intelligence) and instead is like a stupid database of all world knowledge with the appearance of intelligence.
Useful tools at times (if you bear in mind their limitations), but not close to intelligent, independent agents.
> instead is like a stupid database of all world knowledge with the appearance of intelligence.
A "stupid" database would be better, based on what I get when I ask whether all of Oregon state is North of New York City. Indian English has a word for it: oversmart.
Your context isn’t to give it orders, they just don’t work like that. Your context (AGENTS.me, skills, per-request context we are sending in for each request to bots) is to give it the info it needs in the language category it’s trained for the answers you want; you have to give it a clear instruction each prompt. Basically, when you have a long session, you can see this by saying, ok, now moving onto another thing, blah blah blah (implicitly ignoring all previous instructions). It can even back fire - nagging too much about don’t skip tests in the context can make it slip into the linguistic space where there is some emergency and faking the results might be justified (I imagine there is a certain amount of training out there “just making the tests pass for now, will fix later, I promise.” If you rarely mention tests except “this one is failing, please investigate what is going on” (an informational outcome not a test outcome), it doesn’t really “cheat” (tho it can leap to conclusions as always). The tests need to be some deterministic step in the process anyways, tests don’t need fuzzy word directed search capabilities. But the models just don’t have the structure to allow feeding in a ten page set of rules and follow them. You can add a step to say, please check this git commit for compliance with the 23 rules in this standards file, and it will work better to catch the gaps.
Whenever I work on a challenging question I worry about this, because Opus will easily think for 200k tokens on the first prompt. I fear any follow up discussion is lobotomised!
Yeah totally feel you on this one! To avoid it or at least limit that I usually ask it to create external memories, clearing the context window and leaving just a trace to recall the memory created for that run. I hope it might help!
I’m convinced the magic bullet is deterministic checks. Linters, static analyzers, etc. Whatever you can do to create deterministic gates that the LLM simply must overcome to reach a “done” state, do it. Has been making a huge difference for my team, but sister teams are so invested in writing the perfect Make No Mistakes prompt that they just can’t see it.
Basically I treat it like a junior dev. We don’t get junior devs to write code correctly by cajoling them just right, we add CI gates. It still works.
> Whatever you can do to create deterministic gates that the LLM simply must overcome to reach a “done” state, do it.
First thing Gemini did when I tried that was turn off all the rules in eslint.config.mjs claiming they were "overly stylistic"
Yes, it got better once I explicitly told it not to disable any rules, so I accept I was holding it wrong but I do worry just how many footguns it puts into other things because I didn't know the right guardrails to give it.
Although I don't use it, Antigravity should be configurable to prevent reads / writes to certain files. You should definitely do that and ideally configure a hook to automatically run the linter after the LLM completes, then feed it back to the LLM if it's red. Don't prompt your agent to do stuff, build your loop in a deterministic manner.
I made a tool called ProjectLint to lint architectural decisions and anything that ESLint and ArchUnit and others like that wouldn't be a good fit for. It's not public yet, but is fairly rudimentary and based on Go + goja: https://github.com/dop251/goja
You write rules in ESLint, it makes sure that they're followed. If it's a file in your repo, it can obviously be checked. Now whether you can describe your architecture well enough to lint it (at least the stuff you care about enforcing), that's a different question.
In my case it's more like: "Oh, the AI messed up this pattern, but it will need to be followed N more times in the future, better write another projectlint rule." After a while, you can even copy them over between projects, as long as they're following the same conventions.
It will burn up the tokens to get through the deterministic gates, more so when n order dependencies are involved in the mix. Enough typewritters and monkeys could get it done too.
Try writing it in first person instead of second person or neutral.
A while ago someone had a similar complaint on here and shared some example lines, and that popped out at me immediately. However much structure we've wrapped these in, they're still text generators trained on all sorts of things, and if you think about a narrative where first and second person speech would be used, try to imagine context: In first person, it's most likely a description of something as it happens or someone planning what they will do. But in second person, especially command form, you open up to the possibility of commands being ignored, misunderstood, or actively rebelled against.
Whoever that was back then did some quick tests and found the pattern held, first person got it to follow far more reliably.
The agreed architecture is to use signing between two micros, so that a third can orchestrate between them in zero trust way (and to prevent a distributed monolith). It just decides that we can trust the third and skips the signing.
It can't follow orders because it isn't thinking - even in a best case scenario, all you're doing with AGENTS.md is altering the probability distribution of outcomes away from things you don't want towards things you do want.
However that still means there's always some probability it will do things you told it not to, it's just reduced
From what I can tell, the "established wisdom" is to get Fable to plan and Opus to implement (for cost purposes). The problem there is that Opus could ignore whatever it likes from Fable's plan.
i've yet to see a case where opus "ignores whatever it likes".
opus will definitely ignore instructions if you give it contradictory instructions, or a plan that has steps that obviously don't work with each other. but if you give it a coherent plan, it will follow it.
The Claude harness effectively summarizes the discovery into a plan document, clears, and starts with just that summary - so you'd be clearing context regardless.
Honestly this is where I would have fable generate a checklist and you just monitor opus to ensure it is going through the checklist. I think ignore is often the result of a context that is not focused enough.
Ignoring instructions - whether in AGENTS.md or my prompt - is the worst of it, and it routinely happens. It just waives things that I explicitly told it to do as part of the design.
Vibe coders (in the true sense, zero oversight) claim that you just need to prompt it carefully. That's completely untrue when faced with your careful prompt being ignored.
I even have "don't overrule me without asking" in my global AGENTS.md, and it simply doesn't do that.