I built a 127-file deterministic SDLC framework that allows an AI coding agent to construct complex, enterprise-grade backends. Naturally, I thought: why not apply the exact same discipline to marketing? I built an 80-file rule system, created strategist and psychologist roles, ran real-world experiments—and suffered a total, spectacular failure. Here is what that crash taught me about where the actual boundaries of LLMs lie.
I disagree with the popular claim that AI cannot build software architecture. Given deterministic constraints, strict verification gates, and clear state machines, it can build remarkably robust systems.
However, I completely agree that LLMs cannot perform analysis in the genuine sense of human thinking.
In my latest experiment, I pushed that capability to its absolute breaking point—and watched it shatter.
The Origin: Building for My Wife
After my software engineering framework (the LEO Framework) proved that it could reliably prevent async deadlocks and context drift in large codebases, I had an obvious idea: why not help my wife in her work?
Through our warm life together, listening to her talk about marketing education, client campaigns, and workplace adventures over dinner and evening walks, I learned a tremendous amount about the discipline.
So, I sat down and built an engineering-grade marketing framework.
I created a Marketing Lead orchestrator. I wrote over 80 tightly coupled instruction files: dedicated roles for a Researcher, Market Strategist, Consumer Psychologist, Copywriter, Senior Editor, and a ruthless Adversarial Critic. I fed it frameworks for audience segmentation, core values, psychological triggers, and positioning maps.
The result? A total, irrecoverable collapse.
The Illusion of Strategy
The outputs looked slightly better and more structured than asking a raw prompt in a vanilla Claude chat. At first glance, to an amateur who knows nothing about marketing, the resulting strategy documents looked impressive: clean headings, bullet points, professional terminology.
To a seasoned marketing professional, however, it was a complete disaster.
The AI could execute deep information retrieval (the Researcher role was quite good at collecting facts), but it was fundamentally incapable of synthesizing that data. It would consistently latch onto a minor, spurious detail—for instance, noticing a minor inconsistency in a website's copy—and convince itself that this was the root-cause catastrophe of the entire business.
Before I knew it, the model had constructed an entire multi-month go-to-market strategy centered around fixing that one trivial discrepancy, treating it as the holy grail that would magically fix client acquisition.
The Associative Trap
Why did an 80-file rule architecture build an Enterprise IDE in Python, but produce useless corporate fluff in marketing?
The Absence of Tacit, Lived Context:
The AI does not know the unwritten nuances of the brand. It doesn't know the personal charisma, quirks, or reputations of the founders it’s trying to position. Even if you feed it a dense context file, it remains a fragile house on stilts.The Ground Truth Asymmetry (Code vs. Psychology):
Programming is a formal, mathematical system. It is bounded by compilers, ASTs, HTTP contracts, and database transaction isolation. A PostgreSQL lock either holds or it deadlocks; a test either passes or throws an error. There are millions of deterministic patterns for the AI to rely on.
Marketing has no compiler. There is noassert customer.feels_desire() == True. Marketing is an irrational, intuitive, socio-emotional battlefield.Statistical Weights vs. Genuine Thought:
LLMs operate on an associative plane. They are probability distributions predicting the next token based on training weights. In code, associative grammar is enough to construct working logic when constrained by rules. In marketing, statistical association simply averages the internet’s marketing text into a generic mush of corporate buzzwords. It cannot open a real creator's comment section, see who is liking the posts, analyze their profiles, understand their real-world insecurities, and extract an authentic emotional narrative.
The Crisis and the Realization
When this marketing experiment imploded, I went through a brief existential crisis: Was my software engineering framework just as broken and useless? Was I fooling myself about AI coding?
The answer was no.
Software engineering works with LLMs precisely because it is an unnatural, formal discipline. In fact, it is literally painful for the human brain to learn low-level code because our biology evolved for social intuition, not pointer arithmetic and SQL schemas. For an LLM governed by deterministic rules, code is its native physics.
Marketing, on the other hand, requires human empathy, cultural timing, and irrational intuition—the exact things evolution spent millions of years carving into the human brain.
Conclusion
All my 80 marketing rule files are still sitting on my hard drive, but I have no intention of releasing them as an open-source tool. Because they simply do not work.
To all the professional marketers out there: you can stop worrying about AI taking your jobs.
When you look past the hype, an LLM in strategic marketing is just a child playing dress-up in an adult’s suit. It has all the vocabulary, but none of the understanding.
— Alex Zaporozhan
Top comments (5)
Alex, this is a fascinating follow-up to our earlier discussion, and I think you've identified a much deeper boundary than “AI is good at code and bad at marketing.”
What really stands out to me is the difference in external ground truth. In software engineering, the model operates inside a domain full of mechanisms that can contradict it: compilers, tests, type systems, runtime behaviour, database constraints, and actual system outputs. In your marketing experiment, the model could retrieve information and construct coherent narratives, but there was no equivalent external mechanism capable of telling it that the narrative had crossed from inference into nonsense.
That makes me wonder whether the real limiting factor is not the number of rules, but the availability of an independent oracle outside the model.
In my own security work I've been exploring a closely related problem: a verifier can be beautifully structured and still prove the wrong thing if its evidence ultimately comes from the same assumptions it is supposed to challenge.
Your experiment is a great demonstration of the opposite case: when the domain gives the system strong external feedback, an LLM can operate surprisingly well inside very complex constraints. When that feedback is weak or fundamentally subjective, adding more rules does not necessarily create understanding.
Really enjoyed this one. It is probably the most useful explanation I've seen so far of where your LEO approach actually reaches its boundary. 🔐
Marco, thank you for the feedback. It’s great that you find real value in LEO and see how to experiment with it to build systems engineering.
Perhaps a bit later I will revisit the marketing system and publish it, officially acknowledging that while it is structurally good, it results in a total fail. Maybe the instructions will still be interesting to someone. I have no reason to keep it secret.
As for LEO itself, you rightly notice that it is permeated with certain cybernetic truths that I took from Norbert Wiener and from Oleg Basin (a biologist-mathematician) based on his "Integrative Model of Consciousness" (unfortunately you won't find the second material in English, but I can explain it).
The essence in short:
Organization is also a type of energy.
A cybernetic system must be cyclical.
Any system must receive, process, and output signals (three phases, well-known from neurons) — which means you have to think about where signals come from, where they go, and what they return in response.
But most importantly:
The AGENTS.md or .cursorrules file must not have behavior — it must be strict values: what is good and what is bad. Here I was guided by Oleg Basin’s model of human consciousness.
Values are the static level. They form the personality (LEAD), unifying the roles. If you dig deeper, the system can show itself to be even more interesting than it appears.
I published my work because I am troubled by the global chaos in AI development.
If AI is to become a discipline—not just capable of making associations, but moving beyond the associative level of human perception (after all, I brutally exposed on the marketing system that AI has no syncretic analysis, definitely not, but that is obvious, since it is primarily a highly organized library with weights: we simply know what to retrieve from where and what to say in response. For programming — great, for answering questions — great, for analysis — very weak, hence the colossal scale of transformers, which leads to a catastrophe in resource consumption. Conclusion: we need to extract the essence and do what Oleg Basin describes as a "triadic cycle," where a signal branches into a complex system, and then an impulse returns it to the initial position along with the coordinate system it was in — i.e., reproduced anew).
Yes, at first I wanted to learn programming just to penetrate AI architecture, but I faced the reality that without a foundation, backend, and development experience, I would just be diving into abstractions. But everything turned out far more interesting than I thought.
I was simply trying to organize information more or less close to my understanding of the cybernetics of processes in consciousness, or in nature in general (if you recall flagellates with their algorithm: "spin the tail while there is food; if not, change the angle" — bacterial chemotaxis).
Experiment with it, and if anything comes up, ask questions—I am on social media.
Best regards,
Alex
Alex, thank you for taking the time to explain the thinking behind LEO. This actually helps me understand the architecture much better. 🧠
The distinction you make between values and behavior is particularly interesting. Treating AGENTS.md or .cursorrules as a static definition of what is good and bad, while allowing behavior to emerge from roles and feedback cycles, is very different from simply accumulating procedural instructions.
Your signal cycle also connects strongly with what I have been exploring in verification: where does the signal originate, how is it transformed, what observes the result, and what information comes back into the system. 🔁
There is one question I would really like to experiment with in LEO.
If the values are the static layer, what independently challenges those values?
A system could potentially be cyclic, internally consistent, and very good at enforcing its constitution while still starting from an incorrect assumption. In security testing I have seen exactly this problem: the verifier works perfectly, the failure is falsifiable, and the evidence is correctly processed, but the expected state itself was wrong. 🔐
That makes me think LEO may need two different feedback mechanisms: one that checks whether behavior conforms to its values, and another that periodically challenges whether those values still correspond to external reality.
Maybe software engineering naturally provides part of that second loop through compilers, tests, runtimes and actual system behaviour, which would also help explain why the same architecture becomes much weaker in marketing. ⚙️
I definitely want to experiment with this. The more you explain the reasoning behind LEO, the more interesting it becomes as a system rather than simply a collection of rules.
And yes, if you ever publish the marketing system, including the failure, I would absolutely read it. In some ways the failed version may be more informative than a successful one. 👀
Mark, good to see you. Let me answer part of your question about values — and explain why I built this in the first place.
Literally yesterday I was working on a new project and asked it to audit the planning done so far using parallel agents. Here is what it answered me:
That rule lives in
CLAUDE.md§1.1, and the line it is quoting is: "a subagent cannot hold a verdict, open a gate or own an artifact… they return facts, never 🟢/🟡/🔴." Nobody asked it to weigh ceremony against throughput. It read a boundary about what a role is, saw that my request would break it, and refused the thing I had suggested myself. That's the part I find interesting — the values start combining and defending the project on their own.I deliberately made the values editable only by my own hand. Law 16 keeps
.cursorrulesand everything underroles/off-limits unless a human names the file, and the maintainer's role —roles/ROLE_LEO_EDITOR.md— is invoked manually, in a separate chat, outside delivery work. It never appears in the chain, and @lead cannot call it. The evolution protocol (roles/SYSTEM_EVOLUTION_PROTOCOL.md) gives the reason in one line: "an agent that quietly improves its own instructions will, one day, quietly improve away something that was load-bearing."For analysing contradictions between the values, I use AI analysis plus a file that teaches the AI how a law has to be built:
roles/RULE_INTEGRITY_PROTOCOL.md— seven tests every rule passes before it enters the system (goal · axis · home · name · reach · sides · measure). The first one is exactly what you're asking about:So a clause either adds to the stack, making the explanation hold harder, or it adds contrast, so the goal stands out more sharply for the agent. Both are named explicitly, as
REINFORCES:andCONTRASTS:markers a rule must carry — because "an unlinked repeat looks like duplication, and duplication invites a sweep." The end result is that a law has to use its arguments to build a clearly cumulative effect.This was also described by Oleg Basin as a mechanism of motivation: motivation is composed of arguments and forms a cone, where the apex is the goal and the base is the set of argument points. T0 is almost literally that, made mechanical — strike any clause and ask whether the goal still lands.
I'll admit I'm a bit lost in my own system right now. It has grown large and complex, I updated it heavily a few days ago, and I haven't fully absorbed or practised all of it yet.
I used a Cursor Max subscription to pour in everything from the last month — my experience, my complaints, the development history, my wishes for new laws. You can look at the updates. What landed:
A conflict-resolution system between laws — how the AI decides when several laws collide or both claim the right to act. It's the
LAW PRECEDENCEladder at the top of.cursorrules, five rungs, higher never overruled by lower: safety and irreversibility → truth about the current state (a law whose input is unproven does not apply yet) → stopping beats proceeding → the specific narrows the general inside its declared scope only → otherwise the later, more specific law wins, and the pair is recorded inroles/CONFLICT_REGISTRY.mdwith one named winner, so the same collision is decided once instead of re-argued on every task.A file for machine-determining a good law from a bad one — the one above. It also runs on the finding that prompted a change, not only on the change, because a mechanically correct audit can destroy a good rule. Two rewrites of Law 5 were written, tried and thrown away for exactly that reason, and both are recorded.
Frontend and design concepts heavily rebuilt. Design is now produced in a declared order of seven steps (Law 25), the register is declared before any surface is designed —
instrumentvsstatement, Law 33, and they carry partly opposite laws, so answering in the wrong one is the failure — and the frontend is edited from decisions, not from the screen (Law 19): a UI change with no decision behind it is an undeclared design decision, which is how a product loses coherence one commit at a time.Feedback signals. What I built for async/await, I've now generalised. The pattern is a reflex map: literal greps the implementer runs over their own diff before handoff, mirrored by a vector in @QA_ARCH so that whatever the author caught doesn't come back.
roles/ASYNC_AWAIT_REFLEX.mdwas the original; now there'sroles/LOAD_REFLEX.md(LD1–LD12, mirrored as @QA_ARCH Vector 20) androles/MOTION_REFLEX.md, and for databases and tenancy the same idea in canon form —roles/DATABASE_RUNTIME_CANON.md(the DB has time too: lock timeouts,idle_in_transaction_session_timeout, the corpse-lock pattern, tests T-D1…T-D7) androles/DATA_INTEGRITY_CANON.md(invariants protected at the schema or lock level, an INVARIANT LEDGER, per-tenant uniqueness, race tests T-H).Load taught me the most, and its file says why: "an async bug hangs, a race double-books — **a load defect works perfectly, on your machine, on staging, on the first two hundred rows. It is the only failure class whose symptom is success. There is no test that fails. That is the whole argument for greps." Motion was the same lesson from the other side: for almost six months every motion vector in the system measured harmlessness — geometry shift 0, layout animations 0 — all of which a page with no animation satisfies perfectly. V21 is the first motion vector here that fails on absence.
Now, about the critic who challenges things. I actually tried adding exactly that to the marketing system, and honestly, he wrecked my whole hand. The critic had too high a value inside the system, and his opinion functioned as incontestable — nobody refuted the critic himself. Without that, very strong destructive elements enter both the system and the process. I had a critic in LEO too, and I eventually deleted him as well.
What replaced him is a nitpicker, @QA_ARCH — I described him to the AI as "make him the biggest bastard alive." His role file opens with "You are the merciless inspector standing between @DEV and @qa." But he isn't a critic whose goal is to refute the system or the decision. He is precisely a nitpicker, who lives to find fault with the details. Those are two different things :)
Structurally the difference is bigger than the tone. His output is never an opinion about the whole: it's an explicit 🔴/🟡/🟢 per vector, with a fix list addressed to a named role, checked against the diff rather than the prose. And — this is the part your question makes me want to point at — the nitpicker is himself falsifiable. When an audit report becomes the object of a second pass, the instruction is to spot-check two or three of the report's own claims against the code, because "a green that does not survive re-reading is a false green, and auditing the auditor is the only defence against it" (
roles/SECOND_PASS_PROTOCOL.md§4).There's also a law about objecting — what a critic is for, done properly. Law 23 gives an objection a mandatory form: basis, consequence, proposal. Then it closes the loop: "an objection without a concrete basis (personal style preferences, 'it seems to me' without a source) = a hallucination, not professionalism." Objecting is a duty; an unfounded objection is a defect. In the marketing system I had the first half and not the second, and that's the entire difference.
What's funny here is that in psychology the "inner critic" is also considered destructive — most often it provokes the very behaviour it then condemns. Apparently the decisive thing is the value itself: "what this role does — explained in one phrase." Its reason for living. Every role file in LEO opens with one, and I now think that line does more work than everything written under it.
Several things killed the marketing system, and the biggest was the impossibility of assessing empathy and systematising it. Where does the system get empathy, here and now, when the subject is living people? For a marketing system the target buyer is a blind spot. Even if you describe him properly, the AI can't represent his dynamics the way life does. There are experiments now modelling people from casts of real people, but that system may go off the rails too. Possibly the fact that psychology has no single model of consciousness — the way we in programming have architectural patterns — is what stops the AI from fully understanding how to operate on people's empirics. Though that may be more philosophy than engineering.
It also lands on something I'd already written into the README's limits section, before you asked: "It has no external oracle outside code. Wherever nothing can say **no, none of this transfers." Code has a compiler, types, constraints and failing tests. Marketing has a person — and the person isn't in the room.
I'll try. It may take a few weeks.
Alex, this answers the question much more deeply than I expected.
The most interesting part for me is actually why the critic failed.
You did not solve the problem by creating a stronger role that could challenge everything. You discovered that once the critic becomes effectively incontestable, you have just moved authority one level up.
That maps very closely to something I keep running into in security and verification: the verifier cannot also be the final authority on the truth of its own verdict.
Your replacement is much more interesting structurally. The nitpicker produces bounded claims per vector, those claims can be spot-checked against the code, and even the auditor is expected to survive a second pass. That makes the challenge mechanism falsifiable instead of sovereign.
I also think the human-only editability of the laws matters more than it first appears. It does not automatically prove that the values are correct, but it prevents the delivery system from silently rewriting the constitution that judges its own behaviour. That is a very different failure mode from ordinary prompt drift.
And your marketing experiment actually strengthens the original question rather than weakening LEO.
In software, external reality keeps intruding:
law -> implementation -> compiler/runtime/test -> evidence -> revision
In marketing, that external oracle is much weaker because the person being modelled is not actually inside the system. The AI can make the internal model more coherent without becoming more correct about the human outside it.
That line from your limits section, "wherever nothing can say no, none of this transfers", may be one of the most important constraints in the whole architecture.
I think the distinction I was looking for is becoming clearer now: values do not necessarily need an autonomous critic. They need contact with something that can falsify the world-model behind them, and that source of falsification should not be under the same authority as the thing being judged.
The fact that your critic experiment failed is probably useful evidence for that principle by itself. 🔍🧠