The AI-assisted Critical Simulation Method
— an explorative problem solving framework
via generative AI & hypercognition techniques
BACKGROUND
After 15+ years working in international teams of startups / corporate, I left IT to find what I want to really do. I started teaching AI, but I soon realised it wasn't AI I am teaching per se, not like the typical "AI tools" what is taught everywhere. The journey started here, trying to define what exactly is what I want to teach. I realised it is more like AI-assisted workflows for non-devs / non-tech people, AI-assisted problem-solving what can be applied for professional and personal projects as well. The issue was, I had it all in my head: I have a very strong deep drive how I use AI 24/7, and a slowly crystallising intuition that this is not like how others use. The more I taught and discussed AI usage habits with others - I even made a questionnaire & research paper on it -, the more I realised I do something quite differently. I have a hypothesis now that certain cognition styles simply handle AI differently than the rest of the users. This cognition style is common in the hyperassociative / highly structured auDHD / neurodivergent ones; but also in more senior software engineers with a lots of mental models; and also in Gen Alpha / young intuitive tech-savvy kids who has truly zero background in mental models or structural thinking but are highly motivated and forever curious. This is the entry point I started to work on extracting this cognition + AI usage style, and figure out validation of the hypothesis alongside with formalising this into a teachable framework.
This is the first published draft of it.
Abstract
The framework: multi-session, open-ended, generative exploratory process for ill-defined personal/professional problems, with ND cognition as the underlying mechanism, narrative/simulation construction as the operating mode, and human-directed (not AI-directed) adversarial pressure.
The journey so far
Starting point: "I use AI very well but I don't know why, and I want to extract / teach it."
Arc:
- AI teacher framing → AI is only the instrument, I teach problem solving
- Problem solving → actually a methodology / framework
- Methodology → not widely documented in this density anywhere
- Framework → needs extraction from tacit knowledge, formalisation, and a vehicle to reach the right people
The core claim (sharpened)
I use 15+ cognitive operations in high density, in combination, in correct sequence. Most people use 1-2 occasionally. The gap is not intelligence --- it's a transferable system that exists currently only as tacit / implicit knowledge ("készség szint") inside me.
The framework works for exploring unknown models: arriving with a partial, chaotic blob and massaging it into a structured system with fluid, ever-branching edges. Like a scientist encountering an unknown phenomenon and reconstructing its internal logic.
Three layers of what I do (the extraction target)
Layer 1: Use cases (what I use AI for)
My sessions are project-shaped, not query-shaped. I open a context and work a problem to completion. Key use cases:
- Situational modelling
- Research-before-execution (each session = a single project)
- Cognitive scaffolding / external brain
- Multi-variance analysis of dilemmas
- Predictive / scenario analysis
- Self-reflection and psychological processing
Diagnostic signal: most users fire single shots; I manage projects inside AI sessions.
Layer 2: ND cognitive style patterns (linguistic fingerprint)
Not the primary teaching target, but the explanatory frame for why this comes naturally to me and is harder to teach. Key traits:
- High semantic density in prompts (parameter-dense, multi-layered, negative-constraint styling)
- Non-linear fractal branching: each answer generates 2-3 new questions that expand scope
- Hyper-associative cross-domain transplanting
- Metacognitive drive: constant model-checking, not just answer-seeking
- Hypothesis thinking by default: holding competing explanations without collapsing prematurely
Layer 3: Cognitive operations / techniques (the core teachable system)
See full taxonomy below.
Full technique taxonomy (Layer 3)
Clustered by function. Named here for reference --- the actual teaching unit is scenarios, not names (see Open Questions).
Category A: Problem space construction
Before substantive AI interaction begins.
- Wall-of-text context dump --- front-load full context with embedded A→B gap. Question comes last or not at all. Most people ask first, context-drip after. Invert this.
- Scope pinning --- define explicitly what's in/out of this session before going deep. Sprint planning applied to a conversation.
- Outcome contract --- state what a good output looks like: format, decision criteria, success condition. "By the end of this I want to be able to choose between A and B with reasons I can defend."
- Multi-factorial cause splitting --- before asking for solutions, decompose all independent variables that could produce the outcome. Build a causal model, not an idea list. Treat causes as competing hypotheses.
Category B: Steering operations
How to navigate mid-session.
- Fractal branching --- deliberately let each answer generate 2-3 new questions that expand scope. The session grows rather than converges until the map is clear.
- Constraint tightening loop --- run output → identify where it's too broad → add one constraint → rerun. Binary search on the solution space.
- Stall detection --- recognise when you've hit the wrong question, exhausted the problem space, or the AI is giving shallow/circular answers. Two stall types: (1) wrong input given, (2) problem space genuinely exhausted. The map is clear when there are no white spaces left.
- Graceful contradiction --- never just "this is wrong/bullshit." Steer with why and direction. Give the model a vector, not a negation. Wildly contradicting a model is how you get catastrophic drift (vibe coding parallel: contradicting the model repeatedly = model suffering and guessing direction = terrible outputs).
- Context isolation --- one thread = one project. No unrelated topic mixing in the same session.
Category C: Adversarial pressure
How to stress-test the model and yourself.
- Steelmanning on demand --- explicitly ask the AI to make the strongest case against your position before committing. Pre-mortem machine.
- Role inversion --- flip the direction: instead of asking the AI to answer, ask it to question you. "Ask me until we get to a solution." "List 100 smart questions about X." Explores unknown unknowns.
- Cross-provider verification --- paste one model's output into a different provider, compare. Exposes hidden priors and model-specific biases.
- Explicit bias detection prompts --- build these into sessions by default: ask for blindspots, narrative overfitting, confirmation bias, counter-arguments, overindexing. Standard system prompt setting.
- Devil's advocate rotation --- you argue against AI, then ask AI to argue against you. Full rotation.
- Differential diagnosis --- "what else could explain this?" before accepting the first answer. Always.
Category D: Perspective architecture / Mentalization drills
Borrowed from psychology. New users usually react: "wait, you can do THAT?"
- Perspective Embodiment / Mediator mode --- populate the session with real people's point of views who have stakes in the problem. Ask AI to faithfully represent each position's internal logic so the conflict becomes examinable. Not roleplay --- diagnostic mediation. Example: family conflict with clashing worldviews.
- Handoff framing --- "I am explaining this to my student who is also reading this." Creates a shared epistemic context, forces surfacing of your own assumptions, calibrates AI output to a real audience gap.
- Third-person self --- describe your own situation as if it happened to someone else to get less self-serving analysis.
- In my place --- how would others solve this situation? What would others do?
- Hypothesis thinking as default stance --- hold multiple competing explanations without collapsing to the most comfortable one. This is a prior, not a technique (see below).
Category E: Output engineering
What you demand from outputs.
- Forcing actionable outcomes --- session isn't done until there's a decision, a next step, or a falsifiable claim. Build this into prompts: "don't summarise, tell me what to do."
- Model interrogation --- ask why the AI gave this output. "What assumption is driving this recommendation?" Surface hidden priors before they propagate.
- Delta prompting --- provide two versions (a framing, a decision, a description from different moments), ask for difference analysis. Extracts movement, not state.
The meta-pattern
Almost all techniques do one of three things:
- Constrain the search space --- parameter constraints, scope pinning, negative styling, outcome contract
- Build a model before extracting conclusions --- context front-loading, multi-factorial splitting, cross-domain transplant, constraint tightening
- Introduce adversarial pressure on your own outputs --- steelmanning, role inversion, delta prompting, devil's advocate
Category 3 is the rarest, most valuable, and most ND-compatible --- it requires holding multiple competing framings simultaneously without collapsing to the comfortable one.
The prior that underlies all techniques
Instead of being just a technique, it's a foundational epistemic stance that makes the techniques work:
Disconfirmation is more valuable than confirmation. Being wrong early is cheaper than being wrong late.
Source: ASD predictive engine. The most painful mistakes are not bad outcomes --- those are survivable if you're prepared. The most painful mistakes are terribly wrong priors ("hogyan nézhettem be ennyire valamit?"). Constant prediction-checking is the response to that. Result: outcome independence --- prepared for all scenarios, therefore not attached to any particular one being true.
This prior is what makes adversarial pressure techniques feel natural rather than threatening. Teaching challenge: how do you teach this prior to someone who finds disconfirmation threatening? Possible approach: "being wrong is ok, being mistaken is not" --- and experiential rather than lectured (spend the first 20 minutes of a session trying to break the student's entering belief; when it survives, they trust it more; when it doesn't, they've just experienced the value directly).
Pull vs. Push System
Push-based (most users): ask → receive → read → ask again. AI drives the conversation shape. User responds to outputs.
Pull-based (my system): arrive with a partial model already constructed. Use AI to extract specific things --- missing variable, counterargument, structural analogy. I decide what gets interrogated next. AI responds to the shape I impose.
Key implication: pull-based requires arriving with a partial model. I never come empty-handed. Teaching challenge: students arrive empty-handed and expect AI to fill them. The switch from push to pull may be the hardest single thing to teach --- requires the student to believe they have something to contribute beyond the initial question.
What this is (and isn't)
Documented in scattered form, never assembled:
- Prompt engineering literature: covers parts of Category A/E, but for technical/developer use only
- Cognitive offloading research (Risko & Gilbert 2016+): theoretical foundation
- Extended Mind thesis (Clark & Chalmers): philosophical foundation
- Socratic questioning in education: covers role inversion and adversarial pressure, not AI-mediated
- Mentalization-based therapy / motivational interviewing: covers Perspective Embodiment, in clinical context
- Rubber duck debugging: primitive version of what I do
What doesn't exist: the assembled, cross-domain, AI-specific, teachable system. Especially not with ND cognition as the explanatory frame for why some people do this intuitively.
The synthesis. The cross-domain transplant from software engineering, psychology, Socratic method, agile --- assembled into a single framework applied to AI as thinking medium --- doesn't exist elsewhere in this form.
What this framework actually is, structurally
Neither teaching, nor coaching, not therapy. Closest category: methodology licensing / practitioner training --- how design thinking, JTBD, or Socratic seminars spread.
A framework at this stage can propagate through:
- Direct application (work with someone's problem)
- Practitioner training (train others to apply it)
- Institutional licensing (org embeds it in workflow)
- Published methodology (paper, book, course)
The Bottleneck (most important structural insight)
The framework only exists inside me. Every engagement requires full presence. No way to pre-filter who will benefit.
Once even one case study is written up and one session structure is documented, people can self-select before committing. Medium students read the description and don't recognise themselves. The bottleneck is always: get it out of my head first, one concrete artifact at a time.
Minimum viable externalization: 10 concrete problem scenarios --- what the student brought in, what I detected, which operation fired, what shifted. One complete case study would likely surface 3+ techniques not yet named.
Open questions / loose ends
- Naming the techniques --- current names are accurate but cold and unmemorable. The actual teaching unit is scenarios-as-memoriters, not technique names. How to design scenarios that encode trigger conditions?
- Sequencing logic --- the techniques don't fire randomly. There's probably an order (context dump → constrain → build model → adversarial pressure). Is that sequence explicit or still intuitive? The sequence is the method.
- Teaching the prior --- how to teach outcome-independence / disconfirmation-comfort experientially, not as lecture?
- Pull vs. push transition --- concrete method for triggering the shift from passive receiver to active puller in a student mid-session?
- Session lifecycle protocol --- how to open (context dump + outcome contract), track (fractal branching awareness), and close (abort condition / map exhausted) a session. Nobody documents this.
- The borrowing operation as meta-technique --- cross-domain framework transplanting is itself a technique. Part of what's being taught is the library of frameworks, not just the operations.
- NT vs. ND transferability --- which techniques are fully transferable vs. which require a non-linear cognitive substrate to execute?
- Validation track (separate from formalisation) --- does ND cognitive profile predict quality of engagement with AI-mediated Socratic dialogue? Research question for ELTE / academic collaborator.
- Hungarian or English?