Recently, a prominent Staff AI Engineer read my post about the LEO Framework (a 120+ file deterministic rule system for AI coding agents) and asked a brilliant, hard-hitting question:
"What happens when your system encounters a genuinely adversarial input — does the chain protocol propagate the constraint, or does the interlocking make it harder to locate the failure point?"
In other words: what happens when the human gives the AI a terrible, contradictory, or architecturally destructive prompt? Will the 120 connected files spread the disease, or stop it?
Here is my raw, honest answer straight from the trenches of a 2-month solo Enterprise build.
As the person who set specific goals for LEO, I can share from my experience what happens in practice and what blind spots LEO actually has when facing adversarial or complex input (and it definitely has them).
To start with—unfortunately, I don't have the capacity to actively develop the framework itself right now. I’d love to add a lot of things, but at this scale, it would consume all my attention, which I physically cannot afford.
Nevertheless, my experience using it continues to accumulate. Right now, LEO is guiding my solo implementation of an Enterprise IDE AI Node Constructor. 100% AI-Native. (The project is under NDA, but my contract allows me to disclose architectural decisions—this was my personal request).
I originally designed LEO with a specific goal: to help a junior developer with zero architectural background build a more-or-less working product close to an Enterprise level. Once I realized the results were actually quite solid (like medCore on my GitHub, which I intentionally open-sourced for researchers just in case I was losing my objectivity on what is "good" or "bad"—that was the first project built on early versions of LEO).
The second stage began when I saw that this result, while a bit clunky, actually held up on a project with 40,000+ lines of code (and not spaghetti code, but fairly structured, cultured code). That fired me up to make LEO bigger and stronger. That’s when the instruction library grew from 90 files to 120+.
I gave the framework a real crash test. I took a freelance gig for a very low rate (which matched the fact that I am not a seasoned engineer, not a RAG developer, not even a mid-level dev). Fortunately for the project, the clients were extremely demanding regarding the technical quality of both the processes and the result. (The goal: build a pipeline that ingests a book into RAG -> LLM text generation -> sends text to HeyGen/Sora for talking-head rendering -> delivers the final video, tests, and a live-avatar based on the lesson text and RAG library to the client dashboard).
Initially, the platform’s task was simply to generate a text lesson based on RAG. Then, as always happens, the scope creep hit. It grew from "just a lesson roughly equal to a $20 ChatGPT window output" to something much larger: a highly structural, unique lesson format.
So, "semantic search in a RAG library" morphed into "Chapter-specific search" + "Atomic chapter-level indexing" + "Batch retrieval." The node schema became: Retrieve RAG -> extract chapter outline -> assemble a lesson based on the outline, rephrasing it but perfectly retaining the structure and core principles of the original, adapted for a completely different niche/product. I considered this a real challenge.
I successfully delivered the task. The whole product took about 2 months, but in the process, I burned through four $200 Ultra Pro subscriptions + $200 on On-Demand API usage. Those who have been doing this longer can judge whether that’s a lot or a little.
The nodes have zero race conditions. (At least, the "lesson" product generates smoothly every single time. The only errors occur if the context window isn't large enough for the "extract chapter outline" node, or occasional edge cases where raw JSON leaks through unparsed).
The resulting text is highly unique to the niche. There is a specific temperature for extracting text from the outline (0.25) and a separate reasoning temperature (0.65—mostly using DeepSeek Reasoner). The text is chunked into scenes, the video rendering is broken down into multi-scenes atomically, and the product delivers a finished video.
Why am I telling you all this?
LEO can now solve genuinely complex tasks. Everything I described above was 100% AI-Native solo building in two months (plus a DB, which includes a centralized multi-tenant architecture where the Primary Organization can push/pull RAG libraries, materials, videos, and prompts to child Organizations).
I’ve built up specific experience and workflows for managing it, because you still have to drive it and know what to monitor.
The character of LEO:
First of all, if the requirements (specs) contain contradictions or weaknesses (adversarial input), LEO might misinterpret the logic. It will definitely try to build it coherently, but sometimes it fails to bring the business logic to a complete resolution (even though it has specific roles like CREATOR and BIZ for logic).
However:
LEO will immediately flag if something is architecturally incompatible. It will explicitly tell you how not to do something if you ask, and explain why. The LEAD role has a mandate for "Professional Pushback" and is obligated to voice it.
Very often it says: "I built X and Y, but I suggest refining A and B if you want. But this is an architectural decision. If you want, I can draft the ADR files, ARCH SPINE, and LEAD DECISION."
Quite often, treating me as a coding novice, it tells me: "This solution contradicts ADR X and Y. I do not recommend implementing this." If I insist, it replies: "Professional Pushback: I still did not execute this. If you really want this solution, I offer these alternatives, and I recommend picking option A (a cheap task closure) or option B (an expensive closure with architectural refactoring)."
LEO documents its decisions. While many might consider this "AI slop," this is exactly how it remembers what, where, and when it decided something. At the end of a project, it can issue a memorandum on exactly why it made a specific decision and why the requested alternative contradicts the entire system.
Often, to the point of my own irritation, I would demand it override the rules and execute a command without even reading its pushback (e.g., when I desperately needed a quick feature to show a client). It would do anything but what I asked. It genuinely only executes code if there is an approved LEAD DECISION -> ADR -> SPINE -> BATCH PROMPT for the Cursor queue. If this chain isn't approved, and you ask it to do something destructive in a single prompt, the logic goes like this: a) If it's a solo prompt -> pushback; b) If the request is buried among 7 other tasks -> it ignores it or writes in small print ("I didn't do this until you answer these questions," or outright ignores it assuming "maybe he won't notice I skipped it").
I haven't integrated the batch creation system into the main structure yet—I just ask it to do it by explaining how. I simply haven't had time. But it's incredibly convenient: a task list of 40 prompts, Cursor Queue, and a couple of meta-prompts between tasks like "If finished -> move on; if not -> refine prompt," plus "Do an audit of the completed work (mandatory)" + a global audit on the finished batch.
If any of this is helpful, I’m glad. Thank you for your time and attention—it was a real pleasure to get a response from you. It would be even better if you find some useful concepts in how the LEO framework is organized, either for yourself or for the broader developer community. Best regards, Alex.
P.S. LEO is excellent at reading logs and actually prefers working strictly from them. It spots egregious violations very easily. Medium ones take a few prompts. Minor omissions trigger a snowball of fixes from the constantly looping "do an audit of the last prompt" which inadvertently touches everything around it. Yes, sometimes it catches critical things completely outside the direct audit scope, because it might miss them during a targeted check.
Note: I mostly work on Cursor using Grok 4.5/4.6, but Claude Sonnet 5 / Opus are the ones that "wear the LEO suit" best. ChatGPT 5.5 can be magnificent, but it inflates reasoning tokens so heavily that costs go to space (though the solutions are beautiful).
Also, regarding the frontend—there are issues. It makes many things quite nicely, but the frontend still suffers unless you write all the specs immediately using Opus or GPT 5.5. The problem is I’ve mostly studied backend, so I don't fully understand how to tune the frontend rules beyond "just a good classic Mantine UI."
P.S. 2. The best part about the documentation LEO "bloats" the project with: besides fighting hallucinations, at the end of a project (especially if you keep the logs), you can describe the problems you faced and how you solved them. Then, using Sonnet 5 or ChatGPT 5.5 outside the analyzed project (otherwise the universal /roles instructions will bleed into local project specifics), you can ask it to refine the roles and passports based on those problems + whatever else it finds itself, to prevent them in the future. I think there is massive room for evolution here.
Final thoughts:
If you want to see how the LEAD role handles "Professional Pushback" or how the MODEL BLOCKER works, the entire LEO Framework is open-source on GitHub:
👉 https://github.com/alex-zaporozhan/leo
You can also read the post-mortem of how this framework prevented async deadlocks in my previous article here: https://dev.to/alex-zaporozhan/i-spent-200-on-one-queue-bug-then-i-built-a-12-node-ai-pipeline-constructor-and-forgot-the-bug-2a0m
Top comments (0)