The AI-assisted Critical Simulation Method
— an explorative problem solving framework
via generative AI & hypercognition techniques


BACKGROUND

Remember The Construct from the first Matrix movie? It was one of the most underrated scene for me so far. This is what we do. If you ever played RPGs as a kid, it is the same. If you ever thought about how writing a novel starts (like any good crime book plot), this is it. You need a 1-2 sentence long complication, as a core dilemma, a starting point, which brings up ten other questions — you have a narrative. You question it, interrogate, destruct, and build up your hypotheses. This is the Method.

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:


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:

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:

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.

Category B: Steering operations

How to navigate mid-session.

Category C: Adversarial pressure

How to stress-test the model and yourself.

Category D: Perspective architecture / Mentalization drills

Borrowed from psychology. New users usually react: "wait, you can do THAT?"

Category E: Output engineering

What you demand from outputs.


The meta-pattern

Almost all techniques do one of three things:

  1. Constrain the search space --- parameter constraints, scope pinning, negative styling, outcome contract
  2. Build a model before extracting conclusions --- context front-loading, multi-factorial splitting, cross-domain transplant, constraint tightening
  3. 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:

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:

  1. Direct application (work with someone's problem)
  2. Practitioner training (train others to apply it)
  3. Institutional licensing (org embeds it in workflow)
  4. 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