A Blueprint for AI That Reasons

In Fiction to Future, I argued that genuine AI intelligence in operations requires three architectural pillars: the capacity to move through system states in time, conversational interfaces that translate between mechanical observation and human situation, and behavioral models that enable genuine understanding of system dynamics. Without these pillars, AI remains pattern-matching on artifacts—sophisticated but blind to the living systems it claims to perceive.

That argument centered around observability, but the three pillars aren’t domain-specific. They’re architectural prerequisites for any AI initiative aiming for genuine intelligence, not just accelerated pattern recognition. These pillars outline what machines need to reason about complex domains, rather than merely recognizing patterns within them.

Consider what the pillars actually require:

The Time Machine demands that AI can inhabit past states, simulate future trajectories, and explore counterfactual alternatives. This transforms analysis from forensic archaeology into experiential understanding. Without temporal capability, AI is trapped in the present moment, unable to perceive how things evolved or anticipate how they’ll unfold.

The Conversation demands that AI and humans achieve shared situational awareness—not prompt-response exchange but genuine mutual understanding. Both parties must be aware of the situation, both must be capable of assessment, both must operate from a shared context. Without conversational capability, AI responds to descriptions rather than inhabiting situations.

The Model demands that AI represents the domain’s actual structure and dynamics, not just patterns in its surface artifacts. Models explain mechanisms; patterns describe co-occurrences. Without structural models, AI can recognize what usually follows what, but can’t understand why or predict consequences of interventions.

These requirements are applicable wherever we intend AI to reason rather than merely react. They’re relevant in medical diagnosis, financial analysis, scientific research, and engineering design—any domain where comprehending dynamics holds greater significance than matching patterns. They’re particularly pertinent to software development.

The Vibe Problem

“Vibe coding” emerged as a term for AI-assisted development where the human provides intent and the AI generates implementation. In its optimistic framing, this liberates developers from syntactic drudgery to focus on higher-level concerns. In its honest framing, it means: don’t even look at the code.

The phrase captures something real. Current AI coding assistants are remarkably fluent at generating syntactically valid code that appears to do what was requested. For prototypes, experiments, and throwaway scripts, this acceleration is of value. The problem emerges when vibe coding meets engineering reality.

Engineering isn’t code generation. Engineering is understanding consequences before acting. It’s perceiving how changes ripple through dependencies, how abstractions leak or hold, how coupling accumulates over time. It’s anticipating where technical debt will compound, which architectural decisions constrain future options, how today’s convenience becomes tomorrow’s crisis.

Vibe coding, by definition, abandons this. If you’re not looking at the code, you’re not engineering—you’re generating. You’re producing artifacts without understanding their dynamics. And the AI assistants enabling this approach lack every capability that’d make understanding possible. Evaluated against the three pillars, current AI coding assistants fail completely.

No Time Machine

Current coding assistants have no temporal capability whatsoever. They operate on the code visible in the current context window. They can’t reconstruct the codebase as it existed last month. They can’t simulate how proposed changes will affect the architecture over the next quarter. They can’t explore counterfactual designs: what if we introduce this abstraction earlier, how would the structure differ?

Git provides artifact archaeology—diffs, blames, commit histories. But commit histories answer the question “what lines changed?” not “how did the architecture evolve?” A codebase’s structure emerges from dependency flows, abstraction boundaries, coupling patterns—dynamics that exist between and across the files we commit. Commits capture symptoms; architecture is the disease progression they symptomize.

Without temporal capability, AI coding assistants can’t perceive the trajectory that led to the current complexity. They can’t anticipate where coupling will accumulate. They can’t evaluate refactoring options by simulating their structural consequences. They’re trapped in an eternal present, pattern-matching on current text without context of how it evolved or where it’s heading.

A clarification matters here. When developers discover that “vibe coding” produces Frankenstein codebases, they often conclude that “architecture matters.” This is correct but incomplete. Architecture is structure at a point in time. Simulation is structure through time. What they actually needed wasn’t architectural knowledge—it was the ability to simulate how their decisions would compound, to project structural trajectories before living them. Architecture without simulation is a snapshot; you can admire it, but you can’t see where it’s heading. The Time Machine isn’t about knowing good architecture—it’s about perceiving architectural dynamics.

A time machine for codebases would maintain:

• Structural memories: dependency graphs at each point in time, showing how modules related to each other as the codebase evolved.
• Boundary memories: abstraction interfaces and their stability over time, revealing where encapsulation held and where it leaked.
• Coupling memories: interaction patterns between components, tracking how dependencies accumulated or were resolved.
• Pattern memories: what constituted normal for this codebase, this team, this domain—baselines against which deviation becomes meaningful.

With such memories, AI could reason temporally: “This module has accumulated coupling to three domains over the past six months. The current refactoring pressure is the predictable consequence. If we extract this interface, simulation shows coupling reducing by 60% and stabilizing. If we continue the current trajectory, the module becomes unmaintainable within two quarters.” This is engineering reasoning. Current AI provides none of it.

No Conversation

Current coding assistants provide chat interfaces, not conversation. The distinction matters. Chat is prompt-response: human describes what they want, AI generates text that appears responsive. Conversation is mutual understanding: both parties are aware of the situation, both capable of assessment, both operating from a shared context.

When a developer asks “what’s happening with the auth module?”, what do they need? Not a description of function signatures. Not a list of recent changes. They need situational awareness: the authentication boundary is accumulating coupling to session management; the abstraction is leaking implementation details into three calling modules; this pattern diverges from the original architectural intent; continuation will create testing difficulties within the quarter.

This response describes dynamics—coupling accumulation, abstraction leakage, trajectory toward problems. Current AI assistants can only describe syntax—what functions exist, what they appear to do, what text is present. The gap between syntax description and situational awareness is the gap between chat and conversation.

Genuine conversation requires:

Shared awareness: Both humans and AI perceive the same structural situation. The human knows intent; the AI perceives architecture. Neither is querying the other—both are reasoning together about shared understanding.

Mutual assessment: Both can evaluate options. The AI proposes interventions with calculated tradeoffs. The human provides domain context that shapes evaluation. Assessment emerges from dialogue, not from a one-way generation.

Common context: Both operate from the same model of what exists and what matters. When the AI says “coupling is accumulating,” the human understands what that means and why it matters. When the human says “that coupling is intentional,” the AI can update its assessment.

Current AI coding assistants achieve none of this. They receive prompts and emit text. The human’s intent exists only as a natural language description, not as a represented model. The AI’s understanding exists only as a token probability, not as a structural perception. There’s no shared situation—only description on one side and generation on the other.

This is why vibe coding works only for vibes. For prototypes where structural consequences don’t matter, prompt-response suffices. For engineering where consequences compound, the absence of genuine conversation means the absence of genuine collaboration.

No Model

The deepest failure is the absence of models. Current AI coding assistants work at the text level—token sequences, character patterns, syntactic regularities. They don’t represent the code structure. They can’t because their architecture doesn’t include structural representation.

This is the equivalent of observability AI that pattern-matches on log text without modeling system dynamics. The parallel is evident: in both domains, AI recognizes what usually follows what without understanding why. In both domains, this makes intervention calculation impossible. In both domains, the result is sophisticated pattern completion mistaken for intelligence.

What models would genuine AI-assisted engineering require?

AST-level structural models: Code isn’t text; it’s syntax trees with semantic relationships. Functions call functions, modules import modules, types constrain values. These relationships have structure that text representation obscures. Without AST models, AI can’t reason about code—only about characters that happen to represent code.

Behavioral execution models: Code executes. Data flows, control branches, state mutates. Understanding code requires understanding these dynamics—what causes what, where side effects propagate, how errors cascade. Without execution models, AI can’t predict what changes break.

Intent models: Development serves purposes. The developer has goals; the project has requirements; the domain has constraints. Without intent representation, AI can’t distinguish cosmetic changes from architectural ones, can’t evaluate whether generated code serves actual needs, can’t recognize when implementation diverges from purpose.

Conceptual domain models: Code represents domains. Business logic encodes business concepts. Scientific software encodes scientific models. Without domain representation, AI can’t recognize when code structure diverges from domain structure—when the map no longer matches the territory.

Current AI coding assistants have none of these. They have language models trained on source code text, predicting likely next tokens based on pattern frequencies. This is recognition without understanding, the same limitation that afflicts AI observability.

The consequence: AI can generate code that looks right—syntactically valid, stylistically conventional, superficially responsive to prompts. It can’t generate code that’s right—structurally sound, architecturally coherent, aligned with intent and domain. The difference between looking right and being right is the difference between vibe coding and engineering.

Ignored Foundations

What makes this particularly frustrating is that theoretical foundations for genuine AI-assisted engineering exist. They’ve existed for decades. The field has simply chosen not to apply them.

Coordination theory provides frameworks for human-AI collaboration. Dependencies create coordination requirements. Different dependency types require different coordination mechanisms. This tells us how to design AI-human partnership in development. It sits unread.

Field theory offers models for understanding forces in complex spaces. Applied to codebases: coupling creates forces, abstractions create boundaries, architectural decisions shape the field through which development flows. This explains why some changes are easy and others hard. It remains unexploited.

Human-computer interaction research has decades of findings on effective collaboration. Shared mental models matter. Common ground must be established and maintained. Turn-taking follows patterns that enable or inhibit understanding. This science of interaction is ignored in favor of chat interfaces.

Promise Theory provides foundations for autonomous agents making commitments. Modules promise interface stability; developers promise intent; AI could promise capability boundaries. This framework for principled autonomy goes unused.

Collective intelligence research offers models for combining individual agents into coordinated systems. How do AI assistants work with developers? With each other? How does intelligence emerge from interaction? These questions have theoretical foundations. Current practice ignores them for isolated chat sessions.

Serious theoretical work exists instead the field listens to influencers instead. “Don’t even look at the code” becomes wisdom. “Vibe engineering” becomes a movement. The work of understanding how machine intelligence could genuinely assist engineering is set aside in favor of acceleration without comprehension.

Another Path

The three pillars from “Fiction to Future” chart the path for AI that reasons rather than merely reacts.

Applied to development:

Build the time machine. Development environments should maintain structural histories, not just commit logs. AI should be able to inhabit past codebase states, simulate future trajectories, explore counterfactual architectures. Refactoring becomes engineering when you can see consequences before committing.

Enable genuine conversation. Move beyond prompt-response to shared situational awareness. Both human and AI should perceive the structural situation. Both should be capable of assessment. Both should operate from a shared context that enables collaborative reasoning rather than one-way generation.

Implement structural models. AI must represent code as structure, not text. AST-level models, execution dynamics, intent representation, domain mapping—these are the foundations for AI that understands code rather than merely predicting tokens.

This isn’t speculative. The theoretical foundations exist. The computational resources exist. What’s required is architectural commitment—the decision to build AI that reasons about code rather than AI that generates text faster.

The integration of the three pillars creates capability greater than their sum. Time machine capability combined with conversation enables immersive understanding through dialogue—”walk me through how this module evolved” becomes possible. Temporal simulation combined with structural models enables counterfactual architecture—”what if we introduce this abstraction earlier” becomes answerable. Conversation combined with models enables collaborative design—AI proposes interventions with calculated tradeoffs, humans decide, both evaluate results.

This is what AI-assisted engineering could mean: not humans prompting and AI generating, but humans and AI reasoning together about structural dynamics, with shared awareness, mutual assessment, and common models. Not vibe coding. Vision coding.

Coda

“Fiction to Future” described the architecture of genuine machine intelligence for operations. The same architecture applies wherever we want AI to reason rather than react—including software development.

The current trajectory of AI-assisted development abandons reasoning for acceleration. Vibe coding generates artifacts without understanding dynamics. Pattern completion produces text without perceiving structure. Chat interfaces exchange prompts and responses without achieving shared awareness.

The three pillars offer an alternative: AI that can move through time, perceiving how codebases evolved and simulating how they’ll unfold. AI that can converse genuinely, achieving mutual understanding with human developers rather than responding to prompts. AI that can model structure, understanding code as architecture rather than text.

The developers who inherit codebases generated faster than anyone can understand them deserve better. The engineers trying to maintain systems where AI assistance created complexity without comprehension deserve better. The teams burned out by technical debt accumulated through acceleration without engineering deserve better.

The blueprint exists. The foundations are available. The question is whether we’ll continue optimizing the vibe—or start building the vision.

Appendix: On Cognitive Architecture

The argument that the three pillars apply to both observability and development invites a question: what else do they apply to? The answer is: any domain where intelligence means reasoning rather than pattern-matching.

This isn’t because the pillars are clever abstractions that happen to generalize. It’s because they describe cognitive primitives—the structural requirements for reasoning itself.

The Time Machine is temporal reasoning: the cognitive capacity to remember past states, predict future trajectories, and simulate counterfactual alternatives. This is how minds handle change. Without it, cognition is trapped in an eternal present—perceiving what is without understanding how it came to be or where it’s heading. Memory, prediction, imagination: all temporal. Any intelligence that reasons about dynamic domains requires this capacity.

The Conversation is intersubjectivity: the achievement of shared understanding between reasoning agents. This is how minds coordinate. It requires mutual awareness (both agents perceive the situation), mutual assessment (both can evaluate), and common context (both operate from shared models). Without intersubjectivity, agents can exchange signals but can’t collaborate—they respond to descriptions rather than inhabiting shared situations. Any intelligence that cooperates requires this capacity.

The Model is structural representation: the difference between recognizing patterns and understanding mechanisms. This is how minds comprehend. Patterns describe correlations—what typically follows what. Models explain causation—why things happen, how interventions propagate, what consequences follow from changes. Without structural models, cognition can recognize but not understand, react but not anticipate, correlate but not explain. Any intelligence that reasons about mechanisms requires this capacity.

These aren’t domain-specific features. They’re cognitive architecture.

The reason current AI systems fail the same way across domains—whether observability or development or medical diagnosis or financial analysis—is that they share the same architectural absence. They pattern-match on surface artifacts without temporal depth, without genuine intersubjectivity, without structural models. They accelerate recognition while remaining incapable of reasoning.

AI systems that lack these capacities don’t lack features. They lack the architecture of thought. No amount of pattern-matching sophistication compensates for architectural absence. You can’t scale your way from correlation to comprehension.